The Ultimate Guide to AI Compliance with Agent ID

The Legal Reality: Article 9 of the EU AI Act mandates a continuous, documented "Risk Management System". You cannot just build an AI, cross your fingers, and hope it doesn't break the law. You must proactively identify what could go wrong, calculate how bad it would be, and prove you fixed it.

Welcome to the Risk Register in Agent ID. This is your command center for tracking every threat to your AI system.

The Ultimate Shortcut: AI-Powered "Auto-Detect Risks"

Don't know what risks to look for? Let Agent ID do the brainstorming for you.

Click the Auto-Detect Risks button.

Agent ID analyzes your system's description and automatically generates a list of highly probable threats tailored to your specific use case.

For example, it might suggest "Data Privacy" (patient data exposure) or "AI Bias" (biased training data leading to misdiagnosis).

It even pre-calculates the Severity and Probability for you. Just review the suggestions and click Add.

Manual Entry: How to "Add Risk"

When you identify a unique threat, click Add Risk.

To comply with the AI Act's requirement for a "continuous iterative process," we split this form into three logical tabs: Scenario (The Threat), Mitigation (The Fix), and Review (The Ongoing Proof).

Here is exactly what to fill out:

Tab 1: Scenario (Identifying the Danger)

This tab proves you have thought about how your AI could fail or be abused.

Scenario Type: The AI Act requires you to look at two things: how the AI is supposed to be used, and "reasonably foreseeable misuse".

Example: Select "Intended Use" if your HR-bot accidentally discriminates against resumes. Select "Foreseeable Misuse" if an employee tries to use your financial AI to generate phishing emails.

Category: What is the technical vector of this risk?

Example: Select "Prompt Injection Attack".

Description: A plain-English explanation of the threat.

Example: "Attacker manipulating prompts to bypass safety rules."

Severity (1-5) & Probability (1-5): You must estimate and evaluate the risk. Agent ID multiplies these to give you a Risk Score.

Example: Severity 4 x Probability 3 = Initial Score 12. Note: Scores above 12 are flagged as High Risk requiring immediate attention.

Tab 2: Mitigation (Fixing the Danger)

Identifying a risk isn't enough; Article 9 requires "targeted risk management measures" to reduce it.

Mitigation Status: Is this a known issue, or have you fixed it?

Mitigation Steps: What technical or process changes did you make?

Example: "Enabled Agent ID Circuit Breaker and turned on strict Regex filtering to block malicious prompts."

Residual Risk: The AI Act states that the risk left over after your fixes must be "acceptable". This is your new score.

Example: Because you turned on the Circuit Breaker, the Probability drops from 3 to 1. Your new Residual Risk score is 4.

Tab 3: Review (Keeping it Legal)

The AI Act demands "regular systematic review". A static Excel sheet from two years ago will fail an audit.

Review Lifecycle (Last reviewed / Next review): Sets a clear timeline. For example, "Last reviewed: 24. 2. 2026. Next review: 25. 5. 2026."

Mark as Reviewed Button: When May 25th arrives, you check the system, ensure the mitigation is still working, and click this button. It creates an immutable audit log proving to regulators that you are actively monitoring the AI.

Owner Mail: If an auditor asks, "Who is responsible for ensuring this AI doesn't leak data?", you need an answer. Assign an email (e.g., security@yourcompany.com) so ownership is always clear.

Welcome to the Data Governance hub in Agent ID. This is where you create a "Dataset Passport" for every piece of data that feeds your AI.

To link a dataset to your system, click Add Dataset. Here is exactly how to fill out the form, field by field, and why it matters to regulators.

1. The Basics & Categorization

Regulators want to know exactly what data you are using and where it came from.

Dataset Name & Version: Keep it organized (e.g., "CV Screening Set v1.0").

Description: A quick summary of what the data contains.

Origin & Provenance: Where did this data physically come from? Article 10(2)(b) requires you to track data provenance.

Internal: Data from your own company databases (e.g., historical sales records).

Public Web: Data scraped from the internet (Warning: High risk for copyright/privacy issues).

Purchased: Data bought from a third-party vendor.

User Generated: Live data inputted by your current app users.

Synthetic: Fake data generated by another AI to simulate real scenarios.

Usage Type: How is the AI using this data?

Training: Used to teach the AI model from scratch.

Validation / Testing: Used to test if the AI learned correctly without cheating.

RAG / Retrieval: Even if you don't "train" a model, if your AI searches a database of company documents to answer questions (Retrieval-Augmented Generation), that database must be logged here.

2. Compliance & Quality - The Engine Room

This is where you prove you didn't just dump raw data into an algorithm.

"I certify this dataset has been analyzed for bias..." (Checkbox): This is a direct answer to Article 10(2)(f). You must actively check if your data unfairly discriminates.

Verification Cycle: Data gets stale. Set how often your team reviews this dataset (e.g., every 90 days).

Processing & Cleaning Notes: Article 10(2)(c) demands you document how you prepared the data.

Example: "Removed all rows with missing values, normalized dates to ISO format, and used a script to strip out email addresses and phone numbers before training."

3. Compliance & Governance (The Deep Dive)

Here, you map the context of the data to ensure it is actually fit for your specific use case.

Collection Purpose: Under GDPR and Article 10, data collected for one reason cannot magically be used for another without checks.

Example: "Originally collected for payroll processing." (If you are now using payroll data to train an AI to fire people, regulators will have a massive problem with this).

Assumptions & Limitations: Article 10(2)(d) requires you to be honest about your data's blind spots.

Example: "This dataset only contains medical records from urban hospitals; it assumes rural patient health metrics follow the exact same patterns."

Bias Mitigation Steps: If you found a bias, how did you fix it? Article 10(2)(g) requires documented mitigation.

Example: "The original tech-resume dataset was 80% male. We used oversampling techniques to synthetically boost female resumes to a 50/50 balance before training."

Target Geography / Demographics: Article 10(4) says data must match the environment where the AI will be used.

Example: "Adults 18-65 residing in the Czech Republic and Slovakia." (If your AI is used in Japan, but trained on Czech data, it is non-compliant).

Dataset Size / Volume: Just a quick metric (e.g., "50,000 records / 10 GB").

4. Privacy & Metadata (Handling the Radioactive Stuff)

The Privacy Checkboxes: Pay close attention to "Contains personal data" and "Contains special categories of personal data" (e.g., health data, race, political opinions).

The Article 10(5) Trap: The AI Act strictly limits using special category data. You can only use it to detect and correct bias, it must be highly secured, and it must be deleted immediately after the bias is fixed. If you check this box, you are signaling to auditors that you are following these strict rules.

License & Retention Policy: Prove you have the right to use the data and know when to delete it.

Example License: "Proprietary / Internal" or "CC-BY-4.0".

Example Retention: "180 days, then auto-delete."

Evidence URL: Simply paste a link to the "paperwork" for this data. This can be a private link to your company's Google Drive, Notion, SharePoint, or OneDrive. If an auditor shows up, they can click this link to instantly see your signed data-purchase contract or your internal privacy analysis (DPIA) proving you have the legal right to use this data.

By filling out this single page, you transform a messy "data swamp" into a highly structured, fully compliant AI Data Governance registry.

The Legal Reality: Article 15 of the EU AI Act dictates that High-Risk AI must achieve an appropriate level of "accuracy, robustness, and cybersecurity". It legally mandates that your system must have "fail-safe plans" to handle errors and must be resilient against hackers trying to manipulate the AI via malicious inputs (like prompt injection or data poisoning).

Writing a security policy is not enough. You need technical enforcement. Welcome to the Guardrails section, your AI's active runtime protection.

Here is how to configure your shield, step by step:

1. Active Protection (Alerts and Stability)

Regulators expect you to know the moment your system is under stress or attack.

Notification Channels: Connect a Slack Incoming Webhook or an Alert Email (e.g., alerts@example.com). If your system hits a limit or a security shield trips, your team gets a proactive warning instantly.

Service Protection (Rate Limits): Article 15(4) requires resilience against faults. By setting a Max requests per minute (e.g., 120) and a Daily request cap (e.g., 10,000), you prevent malicious actors (or broken scripts) from overloading your system and draining your API budget.

2. AI Firewall / Security Shield (The Cyber Defense)

This is where Agent ID exceeds basic compliance and provides enterprise-grade DevOps security. Article 15(5) specifically requires protection against third parties trying to "alter their use, inputs, or performance".

Active Guard vs. Shadow Mode: * If you are just testing, use Shadow Mode. Traffic isn't blocked, but threats are logged so you can see what would have happened.

For production, enable Active Guard to actively block and mask threats before the AI even processes them.

Strict Security (Fail-Closed): If turned on, your AI will block traffic if the logging dependency fails. This guarantees that no prompt is ever processed without an audit trail.

Store Encrypted Payloads: Safely stores the encrypted input and output of your AI model. If a security incident occurs, this allows your team to conduct a full forensic review without exposing sensitive, plain-text data to unauthorized staff.

Enable AI Security Analysis: Activates Tier-2 semantic analysis and asynchronous risk scoring. Instead of relying on heavy deterministic infrastructure, this uses AI to understand the context of a prompt, helping you catch sophisticated, multi-layered attacks.

Enable AI Audit (Async): Runs continuous background semantic checks on captured events. This ensures you have deep compliance monitoring running silently in the background, without ever slowing down the actual response time for your end-users.

Content Blocking (The Core Shields): Toggle these on to instantly comply with the AI Act's cybersecurity mandates against input manipulation:

Block Prompt Injection: Stops hackers from using "jailbreaks" to override your AI's safety rules.

Block Database Access & Code Execution: Prevents the AI from being tricked into generating malicious SQL queries or executable scripts (RCE).

Block Toxicity & Profanity: Block prompts with hate speech and harassment.

Block PII / Sensitive Data (Strict): By default, Agent ID automatically masks and redacts personal data so it is hidden before reaching the LLM. However, toggling this Strict mode goes a step further: it instantly blocks and drops the entire request if any PII is detected, creating a absolute zero-tolerance firewall against data leaks.

3. Circuit Breaker (The Legal Fail-Safe)

Article 15(4) explicitly states that robustness can be achieved via "technically redundant solutions... or fail-safe plans".

Enable Automatic Circuit Breaker: If your AI starts failing rapidly (e.g., the underlying OpenAI model crashes or starts hallucinating errors), this feature automatically blocks traffic to prevent "cascading failures".

You can set a strict Error Threshold, for example: block all traffic if there are 10 errors within 5 minutes.

4. Threat History (Your Proof for Auditors)

Having a shield is great, but auditors want proof that it works.

At the bottom of the Guardrails page, you will find the Threat History. This is your real-time audit log of every possible attack.

It shows exactly When an attack happened (e.g., "37 mins ago").

The Threat Type (e.g., "Heuristic Injection" or "Security Threat") and a visual Risk Score (e.g., 60% Elevated).

A safely anonymized snippet of the Prompt.

The Status proving your firewall did its job (e.g., BLOCKED or DETECTED/AUDIT).

You can easily filter this list and export it to demonstrate to enterprise procurement teams or EU regulators that your AI is actively defending itself.

Welcome to the System Evaluations module. Agent ID does not replace your testing environments (CI/CD, GitHub Actions, etc.). Instead, it acts as your Immutable Compliance Ledger. You test the code; we generate the legally binding proof.

Here is how your engineering and compliance teams will use it together:

1. Define Your Success Criteria (The Benchmark)

Before running tests in your own environment, you must tell the regulator what a "safe" update looks like.

Create a new Evaluation (e.g., "Migration to GPT-4o").

Define your Criteria using simple logic: Metric + Operator + Target Value.

Example: "Hallucination Rate < 2%" and "Accuracy >= 95%".

The evaluation stays in a Pending state until the real data arrives.

2. Ingest Results (API or Manual UI Fallback)

Your engineering team runs their standard tests (using tools like LangSmith, promptfoo, or custom Python scripts) and brings the final metrics into Agent ID. You have two ways to do this:

Automated (API): Your CI/CD pipeline pushes the final JSON results payload directly to our API endpoint.

Manual: If your team doesn't use automated testing pipelines yet, an engineer can simply open the Evaluation in the dashboard and manually type the measured metrics into the generated form fields.

Strict Validation & Scoring:

False-Positive Protection: Whether via API or manual UI entry, Agent ID enforces absolute data integrity. If you leave a required metric blank, the system immediately rejects the submission. We never evaluate incomplete data.

Automated Scoring: Once complete data is submitted, the system instantly compares it against your criteria. If all metrics meet the thresholds, the status turns to Passed. If even one fails, it is marked as Failed.

3. The Immutable Vault (Anti-Audit-Washing)

This is the most critical feature for passing an EU AI Act audit. You cannot alter history.

Cryptographic Lock: The moment an evaluation is scored as Passed or Failed, the record is permanently locked. The UI becomes read-only, and the API rejects any further edits (403 Forbidden).

Append-Only History: Our database architecture physically prevents the deletion of past evaluations. If an evaluation fails or a test was flawed, you cannot simply delete it and pretend it didn't happen. You must create a new one. This creates a transparent, forensic evidence trail that auditors trust blindly.

4. The Compliance Milestone ("Approve for Production")

This is where a technical test turns into a legal approval.

If (and only if) an evaluation achieves a Passed status, the Approve for Production button becomes active.

Your Data Protection Officer (DPO), CISO, or Tech Lead clicks this button to legally sign off on the update.

The Result: The status changes to Approved. Agent ID generates a highest-priority, unerasable Audit Log: "User [Name] formally approved deployment based on successful evaluation [ID].".

Your engineering team now has the legal green light to deploy the code.

The QMS is split into three core workflows: Policies, Evidence Registry, and Change Requests. To comply with strict Enterprise standards, this entire section enforces the 4-Eyes Principle, meaning the person who creates a document or requests a change cannot be the same person who approves it.

Here is how to manage your QMS:

1. Policies (Your Internal Rules)

Article 17(1) requires systematic, written policies for things like data management, testing frequencies, and accountability. Note: While Agent ID provides the secure cryptographic infrastructure (the "binder and the lock"), your company (or legal counsel) must author the actual rules (the "paper inside"). You need to define your own operational standards, such as "How our company communicates with national authorities in case of an incident" or "How our HR department handles data access."

Draft a Policy: Click Create Policy. Give it a Title and Version (e.g., "AI Data Handling Policy v1.0") and write your customized content directly in our Markdown editor.

The 4-Eyes Approval (Dashboard Execution): Once you save the draft, it cannot take effect immediately. To satisfy strict accountability standards, a second authorized Admin (like your CISO or Compliance Officer) must log into the Agent ID dashboard, review the drafted policy, and manually click 'Approve'. The system physically prevents the same Admin from both creating and approving their own policy.

Immutability: Once approved by the second Admin, the policy becomes immutable. If you need to update it next year, you cannot secretly overwrite the old text, you must create a new version row (e.g., v1.1) and go through the 4-eyes approval process again. This proves to auditors exactly what rules were in place at any given time.

2. Evidence Registry (The Cryptographic Proof)

Not all compliance documents can be written in Markdown. You will have external PDFs, Data Protection Impact Assessments (DPIAs), vendor contracts, or architecture diagrams.

Upload Evidence: Click on the Evidence Registry tab and select Upload Evidence. Select the Document Type, give it a title, and upload the file.

Tamper-Proofing (SHA-256): When you upload the file, Agent ID automatically computes a SHA-256 cryptographic hash server-side.

Lock It: Once verified, you lock the file. If an auditor asks for proof that your risk assessment from two years ago wasn't secretly modified yesterday to cover up a mistake, this cryptographic hash provides absolute mathematical proof.

3. Change Requests (Release Gating)

Article 17(1)(a) mandates strict procedures for "managing modifications" of a High-Risk AI system. You cannot just push an update to production because an engineer felt like it.

This workflow directly connects to the Evaluations you completed in Step 5.

Create a Request: When an engineer wants to deploy a new model or prompt, they go to the Change Requests tab and click Create Change Request.

Link the Proof: They fill in the Title and Description, and crucially, they must input the Linked Evaluation ID of a test that has already achieved a Passed status. They can also attach a Config Snapshot Hash for extra technical accuracy.

The 4-Eyes Release Gate: The engineer submits the request. It is now explicitly blocked from deployment. Just like with Policies, a second designated Approver must log into the dashboard, review the linked passed evaluation, and click 'Approve'. This perfectly satisfies the AI Act's requirement for management accountability and modification control.

Welcome to the Incident Reporting module. This is where your technical team bridges the gap with your legal team, ensuring that critical failures are immediately escalated, forensically documented, and prepared for regulatory reporting.

Here is how you handle incidents in Agent ID:

1. Log the Incident

When your monitoring detects an anomaly or a user reports a critical failure, your team must immediately document it.

Click Report Incident.

Provide a clear Title and detail the exact timeline in the Description field (What happened? What was the impact? What are the mitigation steps?).

2. Link the Forensic Evidence

You cannot just tell a regulator, "The AI hallucinated." They will ask for proof.

Use the Linked Event ID field to attach the exact UUID of the transaction from your Agent ID Activity Logs.

This directly connects the written incident report to the immutable telemetry data (the exact prompt, the retrieved context, and the model's output), giving auditors the exact root cause in seconds.

3. Flag for Article 73 Escalation

Not every bug is a legal incident.

Your engineers can assign a standard Severity level (Low, Medium, High) for internal tracking.

However, if the failure breaches fundamental rights, causes physical harm, or severely disrupts operations, the engineer checks the "Serious / Reportable (Art 73)" box.

This immediately flags the incident for your Compliance Officer or DPO, signaling that the legal countdown has started and the national authorities must be notified within the statutory deadline.

While your core application handles the day-to-day user tasks, Agent ID provides the cryptographic identity tracking and the emergency "Circuit Breaker" to prove to regulators that human oversight is strictly enforced.

Here is how you manage Human Oversight in Agent ID:

1. Assign Accountable Operators

Regulators require you to explicitly designate who is responsible for monitoring the AI system.

Go to the System Access tab.

Use the Human Oversight module to assign specific, authorized team members (e.g., your Lead Operator or Compliance Officer) to the system.

These assigned operators are automatically recorded in your official Annex IV compliance documentation.

Instant Revocation: If an operator leaves the company, removing them here revokes their access immediately.

2. Immutable Request Identity

To prove human oversight, you must be able to forensically link every AI action to its authorized owner. We handle this automatically on the backend. Every transaction log strictly records the Request Identity, generating an unforgeable footprint that includes:

Key Name & Prefix: e.g., sk_live_... / Documed key for owner admin

Environment: e.g., prod

Owner Label: e.g., ondasukac@seznam.cz

Created By: The precise UUID of the human or service account that generated the key.

This ensures that no AI agent can spoof its identity. You always know exactly which configuration, in which environment, under which human's ultimate responsibility generated a specific output.

3. The Emergency Circuit Breaker (The "Stop" Button)

Article 14(4)(e) explicitly mandates that humans must be able to interrupt the system.

Agent ID features a prominent, global STOP button directly in the system dashboard.

If your operators detect severe anomalies, hallucinations, or a data leak, they can hit this emergency circuit breaker. It instantly cuts off the AI's access at the infrastructure level, forcing the system into a safe mode until the incident is investigated and resolved.

Welcome to the Documentation Module. We have digitized the brutal Annex IV requirements into a streamlined, developer-friendly workspace. Instead of battling blank Word documents, your team can use our templates and Auto-Fill generators to build compliant documentation in hours, not months.

Here is how to complete your official Annex IV Technical Documentation:

1. Stack Selector & Auto-Fill

Start by defining the core DNA of your system.

Use the Stack Selector to check off your foundational LLM providers (e.g., OpenAI, Anthropic, Self-Hosted) and your Architecture Pattern (e.g., RAG with Vector DB).

Clicking Auto-Fill Details will instantly populate the structural baselines for your documentation, saving you hours of boilerplate writing.

2. General and Architecture

This section maps directly to Annex IV, Paragraph 1 (General Description) and Paragraph 2 (Detailed Architecture).

Version & Release Date: Track the specific iteration of your system.

Market Placement Form: Describe how the user gets the AI (e.g., SaaS, API, embedded hardware).

Performance Metrics: Define your baseline thresholds (Accuracy, Latency, Error Rates, SLAs).

Architecture and Logic: Explain how the components interact. Use our built-in Insert RAG Template or Insert Chatbot Template to quickly map out your data flow.

Instructions for Use: Provide the operational warnings and guidance for the end-user.

3. Development and Infrastructure

This section satisfies Annex IV, Paragraphs 1 and 2 regarding physical deployment and user interaction.

Development Methodology: Detail your pre-trained models, validation steps, and data handling methods.

Infrastructure & Hardware: Describe your compute resources (e.g., AWS, Azure) and hardware footprint.

User Interface & Lifecycle: Describe the operator UI and how you plan to control future updates.

Lifecycle Changes: The AI Act requires you to document exactly how your system will evolve over time. Use this field to describe your change control procedures, update frequency, and any predetermined changes to the model's behavior. This directly ties back to the formal Change Requests in your QMS.

Pro-Tip: Use the Generate Draft button next to each field to let Agent ID draft a legally sound baseline based on your system telemetry.

4. Compliance and Legal

This final section covers the strictest regulatory aspects (Annex IV, Paragraphs 2, 7, 8, 9).

Validation Protocols: Describe the datasets and procedures used in your testing.

Cybersecurity Measures: Check off your standard controls (TLS/SSL, RBAC, Audit Logs, Encryption) and provide a plain-language summary.

Applied Standards: List any harmonized standards (e.g., ISO 42001, ISO 27001) your company follows.

Conformity Declaration & Post-Market Monitoring: Draft your official EU declaration and describe your continuous monitoring plan under Article 72.

5. Export the Compliance Bundle

Once all fields are populated, simply click Export Bundle (located at the top of your dashboard). Agent ID will compile your technical texts, append your immutable evaluations, and attach your cryptographic evidence registry into a single, beautifully formatted, auditor-ready PDF.