Meet Sigigo: Evidence Infrastructure for the GenAI Era

The EU AI Act does not ask whether your GenAI stack can write logs. It asks whether supervised systems can produce durable, authentic evidence about what happened: model, input context, outputs, decisions, under Article 12 record-keeping.

That requirement sits next to GDPR's minimization and retention habits. Traditional logging puts the full conversational payload in a SIEM where it can be edited, deleted, or dumped into discovery. That is a weak place to land when the question is can you prove this later?

Sigigo is evidence infrastructure for that gap. Think of it as an invisible notary for software and agents: when an important event happens, we help you produce a cryptographic receipt you can verify without trusting our UI.

The missing piece in GenAI stacks

Modern agents move money, change records, and take actions that affect people. Teams still reach for the same debugging logs they used for microservices.

Those logs were built for operators, not for courts, auditors, or the AI Act:

• Admins and attackers can alter or delete them
• Vendors can alter what you see in a dashboard
• Payload dumps create retention and GDPR surface you may not want

Processors already have mature compliance tooling. The step that is still thin is tamper-evident evidence of system behavior on the deployer's side, especially for high-risk systems and AI-heavy workflows.

Proof without inhaling the payload

Sigigo's default for sensitive flows is Private Commitment Mode:

1. Your application holds the sensitive payload (prompts, context, outputs) in your vault.
2. You register a signed commitment: a cryptographic witness of that event.
3. Commitments chain into an append-only structure and batch into a transparency log (Merkle-style proofs).
4. Verification uses math and exportable packages, not "trust the blue checkmark in a SaaS screen."

We facilitate the evidence chain. We do not need to store every conversational secret to be useful. Disclosure stays under your control when auditors or counsel ask for the underlying records.

That is the opposite of "post everything forever" and also the opposite of "anonymous / GDPR-free" marketing. Payloads stay yours; proofs and metadata are what make the chain auditable. See our data sovereignty and EU Data Act notes for how residency and disclosure fit.

Crypto-enforceable first (chain optional)

The product core is crypto-enforceable evidence:

Canonicalize, hash, sign, append-only chain, Merkle transparency log, exportable verification.

Optional public anchors are a separate witness tier: batch fingerprints on a public ledger when you choose that posture. Raw prompts and PII never go on-chain. EU-facing deployments default with public anchoring off unless you explicitly enable it for an approved use case.

If someone sells "blockchain compliance" as the whole story, pressure-test whether Layer 1 (tamper-evident evidence you can verify offline) actually exists.

Designed to sit behind your agent runtime

Adoption is meant to be boring: thin wrappers and SDKs at decision boundaries (inference, tool calls, approvals, policy checks), not a second SIEM.

Early surface area targets frameworks and runtimes teams already use (OpenAI-style clients, LangChain, Mastra, Vercel AI SDK, and fire-and-forget / async emit paths). Region-locked tenants and exportable audit packages are part of the design, not an afterthought.

We are shipping this stack in phases. What does not change is the positioning: evidence infrastructure, not another place to dump mutable logs.

Where this goes next

Article 12 is the hard regulatory force function for high-risk AI. The same shape helps anywhere "show me what the system did" must survive litigation, customer audits, or internal risk review.

If you want to talk through an EU or GenAI evidence posture, get in touch. For how we handle privacy, subprocessors, and regional posture as a vendor, see legal & compliance.