Trust & transparency.

Operating posture

What AICVS does and does not do

The risk in compliance tooling is overclaim. We treat the boundary explicitly because regulators read marketing copy and so do compliance officers.

Does

• Hosts a readiness workspace — AI inventory, likely risk classification, suggested controls, evidence vault, vendor due diligence, policy lifecycle, human oversight records and readiness reports based on available records.
• Maps records and findings to specific articles and paragraphs of Regulation (EU) 2024/1689 with verbatim citations.
• Optionally runs Technical Evidence Scans when you upload code or other artefacts — surfaces signals (AI authorship indicators, GPAI integrations, ML library presence, dynamic execution patterns) for reviewers; not a compliance verdict.
• Produces evidence artefacts — readiness reports, audit packs, SHA-256 hash chains, RFC 3161 timestamps, structured PDFs that can be incorporated into an Art.11 + Annex IV technical file.
• Calibrates per-rule false-positive rates from internal review samples and live user feedback (where scans are used).
• Maintains a tamper-evident audit trail for every scan with public verification at /verify/{id}.

Does not

• Does not certify your compliance. Conformity assessment under Article 43 is a formal process. AICVS produces inputs; it does not issue conformity certificates.
• Does not produce a complete Annex IV technical file. The technical file requires risk management documentation, data governance evidence, validation records, and post-market monitoring plans — much of which lives outside the codebase.
• Does not classify your system's risk tier. Annex III categorisation is a legal determination based on intended purpose. AICVS asks you for it; it cannot decide it.
• Does not provide legal advice. Regulatory interpretation belongs to your solicitor or DPO.
• Does not detect every form of AI involvement. Detection is probabilistic; sophisticated AI-assisted development can be hard to detect. False negatives are possible.

Data we hold for each scan

The single most important commitment we make to subscribers is what happens to your source code. Every scan operates as follows:

• Source file is uploaded over TLS to our compute region (Frankfurt).
• File is read into memory and analysed by the six detection layers. Total in-memory time: typically < 3 seconds.
• Source bytes are not persisted. They are released from memory once analysis completes.
• What we store: filename (after sanitisation), language, score, list of findings with rule_id + line number + description, article references, SHA-256 hash of file contents, scan timestamp, RFC 3161 timestamp, user_id, org_id, and your provided system_context (if any).
• The hash proves a specific file was scanned at a specific time. It does not let us reconstruct the file.

For a live machine-readable view of what we hold per scan, see https://api.aicvs.io/api/v1/transparency/data-flow.

Data retention

• Scan metadata (findings, score, system_context): retained for the active subscription period plus 30 days. After cancellation or deletion request, removed from primary database within 7 days.
• Evidence hash + timestamp (just the hash, no metadata): retained 7 years to allow verification of historical technical evidence scan records.
• Account data (email, plan, billing): retained per Stripe and Irish revenue requirements. Deleted on request subject to those constraints.
• Audit log (admin actions, plan changes, login events): 13 months rolling.
• Backups: provider backups may retain deleted records until the normal backup expiry window completes.

Subprocessors

We keep the stack deliberately small so export, deletion, and incident response are practical for a small team.

• Supabase — application database, EU region.
• Render — API hosting, Frankfurt region.
• Vercel — public website and frontend hosting.
• Stripe — payments, invoices, and subscription records.
• Resend — transactional email delivery.
• Sentry — application error monitoring; configured to avoid intentionally sending source code or secrets.
• Anthropic — optional enhanced scan analysis only when explicitly enabled on paid plans; off by default.

Availability & disaster recovery

We are honest about our stage: AICVS is operated by a small team and does not offer a contractual uptime SLA on public self-serve plans. What we do commit to:

• Backups: the application database (Supabase, EU region) is covered by the provider's managed daily backups with point-in-time recovery within their retention window. Backup tier and restore procedure last verified 5 August 2026.
• Restore: our recovery process is a provider-managed database restore; we periodically verify that a restore completes. Target recovery objectives are best-effort at this stage, not contractual.
• Redundancy: hosting (Render / Vercel) and database (Supabase) are managed, multi-tenant platforms with their own regional redundancy.
• Evidence durability: scan evidence hashes and RFC 3161 timestamps are retained independently of scan metadata, so a certificate remains verifiable even if surrounding records are removed.
• Incident response: on a confirmed security incident affecting customer data, we will notify affected customers without undue delay and describe scope, cause, and remediation. Report suspected issues to security@aicvs.io.

Enterprise customers who need defined RTO/RPO targets, a signed SLA, or a formal DPA can request these during procurement — see the Enterprise plan.

Customer export and offboarding

If a customer asks to leave, we can prepare an export of organisation records and run an erasure workflow. The export may include account/team records, AI inventory, role profile, risk classifications, suggested controls, evidence metadata, vendor records, monitoring plans, incident records, generated policies, technical documentation, scan findings, hashes, timestamps, reports, and audit-pack records.

Deletion is handled with a dry-run-first internal tool and a confirmation step. Some records may be retained where required for tax, billing, security, fraud prevention, legal dispute handling, backup expiry, or historical evidence verification. Where something cannot be deleted immediately, we explain why and for how long.

Continuity — what happens to your evidence if we don't survive

We are a small company, and compliance is a multi-year commitment. “What happens to my evidence if you stop trading?” is a reasonable question to ask us and an uncomfortable one to answer, so here is the answer in writing rather than on request.

• Export on demand, in open formats, with no notice period. Your full organisation record — inventory, classifications, evidence metadata, findings, hashes, timestamps, generated documents — is exportable as JSON, CSV and PDF at any time, on any plan, including the free tier. Export is not a retention lever and we will not make you ask for it.
• 90 days' notice before any wind-down. If we discontinue the service, we commit to 90 days' written notice, during which the service stays available for export and no new charges are made. We would rather be held to a stated number than judged on an intention.
• Your certificates outlive us. Every AICVS certificate can be verified with an open-source script (MIT) that needs no network, no account and no AICVS — standard library only, including the signature check. Fetch the bundle from /api/v1/scans/{id}/bundle.json, keep it with your records, and it stays checkable whether or not this company exists. Vendor the script into your own repository — that is what it is licensed for.
• Certificates are signed, not just hashed. Each carries an Ed25519 signature over the terminal digest, so a third party can establish that AICVS issued it — which a hash chain alone cannot show, since anyone holding the inputs could otherwise build a self-consistent bundle. Public keys are published at /.well-known/aicvs-signing-keys.json; pin them yourself, because a key that arrives inside a bundle proves only arithmetic. Retired keys stay published so older certificates keep verifying. What this does not cover is key custody: a signature proves the holder of the private key produced it, and no verifier can check how well we protect ours.
• The evidence format is documented, not proprietary. The six-step hash chain is specified in full in the verifier's README, so a third party can implement their own checker without our cooperation.

What we are not claiming: this is a published commitment, not an escrow arrangement or a bank guarantee, and a company that has ceased trading cannot honour a notice period retroactively. The part that genuinely survives us is the third bullet — a certificate anyone can verify offline, forever, using code we do not control.

Verification & transparency endpoints

We expose a small number of public endpoints designed to let you verify the claims on this page without contacting us:

• GET /api/v1/transparency/data-flow — what we store and where.
• GET /verify/{scan_id} — verify a scan's SHA-256 + RFC 3161 timestamp.
• GET /api/v1/gpai/cop-signatories — current Code of Practice signatory list with verification stamp.
• GET /api/v1/scans/{scan_id}/bundle.json — self-contained certificate bundle for offline verification. Contains no source code.
• GET /.well-known/aicvs-signing-keys.json — public keys certificates are signed with. Pin these to verify origin offline.
• GET /.well-known/security.txt — security contact and disclosure policy.

The /verify endpoint recomputes the evidence chain and reports what actually matched; it does not simply confirm that a record exists.

Frameworks & their honest status

• EU AI Act (Regulation 2024/1689) — primary mapping. 47 articles covered with paragraph-level citations. Updated when the EU Commission publishes guidance. Verified against the OJ L of 12.07.2024 publication.
• ISO 42001 — full mapping for AI management system controls A.6.1, A.6.2, A.7.4, A.8.2.
• ISO 27001 — partial cross-mapping (cybersecurity findings under Art.15 → A.5.7, A.8.25, A.8.28). Not a substitute for a full ISO 27001 certification audit.
• SOC 2 Type II — partial cross-mapping (CC6, CC7, CC8 referenced where applicable). Not a substitute for a SOC 2 audit by a CPA firm.

What we are not

We are an early-stage Irish company with a focused product. We are not a multinational consulting firm. We do not have a public list of Fortune 500 customers. We do not publish testimonials we cannot verify. The right comparison for AICVS is the toolchain a competent compliance officer would build for themselves if they had unlimited time. We compress that build time into a subscription.

Reporting a security issue

If you believe you have found a security vulnerability, email security@aicvs.io. Use our PGP key from /.well-known/security.txt for sensitive details. We acknowledge within 48 hours and aim to resolve critical issues within 7 days. We do not currently run a paid bounty programme but we do credit reporters publicly with permission.

Talking to us

The fastest way to evaluate whether AICVS is right for your team is to run a free scan on a real file from your codebase. The next-fastest is our contact form (topic + consent) or an email to hello@aicvs.io with a description of your stack, your AI Act exposure, and any specific concerns. We answer in business hours, Irish time, with a human.

Last reviewed: 5 August 2026 · Next review: 5 November 2026 ·Page maintained by the team at Rivoryn Limited.