Frequently Asked Questions

AICVS is an EU AI Act readiness workspace. You record the AI systems your organisation uses, classify their likely risk, work through suggested controls, link evidence (vendor due diligence, policies, human oversight records), and generate readiness reports and audit-pack-style outputs for legal/compliance review — based on the records you provide. Not legal certification.

Optionally, technical teams can run Technical Evidence Scans on uploaded source code or other artefacts. The scan engine uses a 5-layer analysis pipeline (Regex, AST, Statistical Stylometry, Structural, Explainability) to surface compliance signals, map them to relevant EU AI Act articles, and produce a tamper-evident technical evidence report for reviewers. Scans are one feature feeding the readiness workspace — not the whole product.

Each readiness report and scan produces a clear status, findings mapped to EU AI Act articles, a plain-English reviewer summary, and an evidence record for your readiness file.

• 75–100 → PASS (green): Few or no compliance signals. Suitable for regulated environments without immediate remediation.
• 50–74 → CONDITIONAL (amber): Some signals detected. Human review required. Address findings before regulatory submission.
• 0–49 → FAIL (red): Multiple or critical signals. Must be remediated before use in any regulated AI system.

Each finding has a severity (CRITICAL, HIGH, MEDIUM, LOW) and a score impact. CRITICAL findings (e.g. exec() calls, AI authorship comments) subtract the most points. Scores are deterministic — the same file always produces the same result.

No. AICVS provides readiness workflows, suggested controls, evidence organisation, technical evidence reports, and audit packs based on available records. It is not legal advice, regulator approval, or legal certification. Outputs should be reviewed by appropriate legal, compliance, or technical experts.

• Layer 1 — Regex (50+ rules): Pattern matching across all 15 languages. Catches AI API calls, LLM attribution comments, ML imports, auto-generated docstrings, TODO/FIXME placeholders.
• Layer 2 — Python AST: Structural analysis for Python. Detects exec()/eval(), monolithic classes (>10 methods), dead imports, low cyclomatic complexity.
• Layer 3 — Statistical Stylometry: Based on arXiv research (2411.04299, 2509.18880). Measures Shannon entropy of line lengths, identifier naming variance, blank-line burstiness, function length uniformity. AI-generated code produces statistically uniform patterns humans don’t.
• Layer 4 — Structural: Cross-file patterns, evidence chain integrity, documentation coverage.
• Layer 5 — Explainability: Every finding gets a plain-English explanation and reviewer note for non-technical auditors.

Optional Layer 6: STAT-008 AI-enhanced perplexity scoring (paid plans, opt-in). Sends code to Anthropic API for semantic analysis. A privacy banner warns you before enabling. Off by default.

15 languages: Python, JavaScript, TypeScript, JSX, TSX, Go, Java, Rust, C#, Ruby, PHP, Swift, Kotlin, C, and C++.

• Free plan: Python, JavaScript, TypeScript only.
• Paid plans (e.g. Workspace): All 15 languages.

Python has the deepest analysis (AST + regex + statistical). All others use regex + statistical. Full AST for Go, Java, and TypeScript is on the roadmap for Q3 2026.

The Merkle chain creates a tamper-evident audit record. If anything changes — filename, score, timestamp, org ID — the hash changes. Reviewers can verify evidence records independently at aicvs.io/verify/{scan_id}.

• Step 1: SHA-256 hash of the file content
• Step 2: Identity hash (filename + scan_id + timestamp + version)
• Step 3: Provenance hash (step 1 + step 2 + score + classification)
• Step 4: EU mapping hash (step 3 + articles triggered)
• Step 5: Merkle root (steps 1–4 combined)
• Step 6: Evidence chain seal (merkle root + scan_id + version)

This helps organise records that may support legal/compliance review under Art.12 record-keeping — it shows a scan happened, when it happened, and what was found, with cryptographic proof of non-alteration. Whether your full record-keeping programme satisfies Art.12 is for legal/compliance review to confirm. Not legal certification.

Those tools find security vulnerabilities. AICVS supports a different question: what EU AI Act readiness signals appear in this code, what articles may be relevant for review, and what technical evidence can you record for human-led readiness work? (Not legal certification.)

Run AICVS alongside security scanners. They protect your code from bugs. AICVS helps identify EU AI Act readiness gaps and organise evidence for legal/compliance review — it does not remove regulatory risk or guarantee compliance.

AI writing detectors analyse prose — sentence structure, vocabulary, tone. They cannot analyse source code imports, AST structure, or map findings to regulatory articles.

AICVS is built specifically for source code and is the only tool that:

• Runs deterministic, reproducible scans (same file = same result, always)
• Maps code signals directly to EU AI Act articles
• Generates a cryptographic evidence chain (not a probability estimate)
• Produces a verifiable, tamper-evident evidence record suitable for audit preparation

Building your own means: writing and maintaining 50+ regex rules across 15 languages, implementing AST analysis per language, keeping pace with EU AI Act guidance, building a tamper-evident evidence chain, and designing review-ready PDF outputs. AICVS is maintained full-time and updates as new AI tools emerge.

More importantly: your internal tool may not provide independent evidence verification. AICVS evidence records are verifiable at aicvs.io/verify/{scan_id} — third-party proof reviewers can check without trusting your infrastructure.

AICVS cannot detect clean AI-generated code with no observable markers. This is the state of the art across all tools — even the best academic detectors achieve ~82% F1 score (arXiv 2411.04299). If all markers are removed (comments stripped, variables renamed), AICVS will score it high — as will every other tool.

This is why we say “compliance signals”, not “AI detection”. A PASS result means no detectable signals were found — it’s evidence of a clean scan, not proof of human authorship.

• Organisation name, user name, scan timestamp (UTC)
• File analysed (name + SHA-256 hash — never the actual content)
• Compliance score and status
• Full findings table with severity, rule ID, line number, EU article, and remediation step
• EU AI Act article mapping summary
• Plain-English reviewer narrative
• The full 6-step evidence chain (each step’s hash)
• Verification URL for independent confirmation
• Version string and AICVS disclaimer

The PDF supports Art.11 technical documentation preparation, procurement due diligence, and legal/compliance review workflows based on available records.

It applies to you if:

• You place AI systems on the EU market — including digital services used by EU citizens, regardless of your incorporation country.
• You deploy AI in Annex III categories: credit scoring, HR screening, fraud detection, medical device software, critical infrastructure, public services.
• You use AI-generated code or ML models that make decisions affecting EU employees or customers.

For high-risk AI systems, providers must compile an Annex IV technical documentation package before market placement. It must include:

• General description of the AI system and intended purpose
• Description of the development process and elements
• Information on training, validation, and testing data (Art.10)
• Risk management documentation (Art.9)
• System version history and change log
• Art.14 human oversight measures assessment
• Art.15 robustness, accuracy, and cybersecurity measures

AICVS PDF evidence reports are designed to be slotted into Annex IV packages as an automated technical evidence layer. They do not replace the full Annex IV package, but reduce manual evidence assembly work.

No. AICVS evidence reports are automated technical review outputs — supporting documentation, not a formal conformity assessment. Think of them like an automated penetration test report: it supports your security claim but doesn’t replace a manual pentest.

They are suitable for: Art.11 technical documentation packages, enterprise procurement due diligence, regulatory investigation responses, academic misconduct proceedings. They are not a substitute for a notified body assessment under Art.43 for Annex III high-risk AI systems.

Never. Your code is read into memory, analysed, and immediately discarded. We store only the scan result: score, findings, and SHA-256 hash. We cannot reconstruct your code from our records — this is an architectural decision, not just a policy.

Yes. We are incorporated in Ireland and process all data within the EU (Frankfurt). We have DPAs with all sub-processors. GDPR rights exercisable via Settings or privacy@aicvs.io.

• Data residency: Frankfurt, EU only
• Code never stored: Only hashes and results retained
• No advertising: Data never shared with advertisers
• Deletion: Full deletion via Settings → Danger Zone

• Passwords: PBKDF2-SHA256, 260,000 iterations, unique random salt per user. Exceeds NIST SP 800-63b. Never stored in plain text.
• API keys: SHA-256 hashed. Raw key shown only once at creation.
• JWT tokens: Expire after 8 hours. Refresh tokens rotate on every use. Revoked on logout.
• 2FA: RFC 6238 TOTP (authenticator app only — no SMS, immune to SIM-swapping).

• Rate limiting: 6 independent buckets — max 10 login attempts/min per IP
• Account lockout: 5 consecutive failures → 15-minute lockout
• ZIP bomb protection: malicious archives rejected at upload
• MIME magic-byte validation: files checked against actual content, not extension
• Path traversal sanitisation: filenames cleaned before processing
• ReDoS timeout: regex rules run with timeout to prevent denial-of-service
• Security headers: HSTS (prod), X-Frame-Options: DENY, CSP, X-Content-Type-Options

Writing-integrity tools are designed for written prose. They cannot analyse source code imports, AST structure, or generate cryptographic evidence for disciplinary proceedings.

AICVS is purpose-built for source code submissions: detects AI API attribution comments, structural patterns characteristic of AI-generated code, dead imports, complexity uniformity, and generates tamper-evident evidence for proceedings.

Universities may use writing-integrity tools for essays and AICVS for code. Neither should be the sole basis for misconduct decisions.

Yes. The cryptographic evidence chain is suitable as supporting technical evidence in disciplinary proceedings, similar to how similarity reports may support written-work review.

It proves: which exact file was scanned, when (UTC timestamp), what findings were detected, and that the record has not been altered since the scan.

• Monthly credit allowance for technical evidence scan runs — sized for typical module cohorts (see Pricing for current Academic allowance)
• Bulk ZIP upload: Drop an entire submission folder as one ZIP, get per-file results
• Technical evidence PDF export per eligible scan run — print-ready records for disciplinary files
• Team features: Multiple lecturers with role-based access
• All 15 languages — covers any language taught in your department

For institution-wide use, contact academic@aicvs.io for Enterprise pricing with LMS integration (on roadmap for Canvas, Moodle, Blackboard).

Technical evidence scan runs use your plan's included allowance. Details and current limits are shown in the app and on Pricing. Outputs support readiness based on available records; they are not legal certification.

Yes. Cancel anytime from Settings → Billing. Cancellation takes effect at the end of your current billing period. No cancellation fees, ever. Upgrading takes effect immediately with prorated billing.

Yes. Email hello@aicvs.io. We offer 50% discounts for: early-stage startups (pre-seed/seed), registered non-profits, EU-funded research projects (Horizon, ERC), Enterprise Ireland portfolio companies, and open-source projects with public repositories.

The aicvs/scan-action@v1 GitHub Action is available now. Add it to any workflow:

- uses: aicvs/scan-action@v1
  with:
    api-key: ${{ secrets.AICVS_API_KEY }}
    min-score: 50          # fail if any file scores below this
    fail-on-critical: true # fail immediately on CRITICAL finding
    post-comment: true     # post results as PR review comment
    paths: './src'         # glob to scan (default: changed files)

Get your API key from Settings → API Keys. Set it as a GitHub secret named AICVS_API_KEY.

Use the CI/CD Wizard in the app (sidebar → CI/CD) for a visual YAML generator.

No. AICVS never requires repository access. You push files to the API — it never pulls from your repo. The GitHub Action only accesses files you specify in paths (default: changed files in the current PR). Your full codebase is never transmitted.

Yes. Full API documentation at https://api.aicvs.io/docs. Key endpoints:

• POST /api/v1/scans — single file scan
• POST /api/v1/scans/bulk — ZIP upload (paid plans)
• GET /api/v1/scans/{id}/certificate.pdf — Technical Evidence Report PDF download (paid plans)
• GET /api/v1/badge/{scan_id}.svg — SVG badge (public)
• GET /api/v1/scans/{id}/verify — public verification (no auth)

Authenticate with Authorization: Bearer <jwt> or X-Api-Key: <api-key>.