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.

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.

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 /.well-known/security.txt — security contact and disclosure policy.

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: 29 April 2026 · Next review: 29 May 2026 · Page maintained by the team at Rivoryn Limited.