Your capstone project: AI Act compliance from start to finish

This module is different from the previous ones. It is not theory with examples. It is a complete practical project that, upon completion, will leave you with an AI Act compliance programme ready to present to your management committee, board of directors or a regulator.

The AI Act entered into force on 1 August 2024. Obligations apply on a phased basis: prohibitions from February 2025, requirements for high-risk systems from August 2026. That is, if your organisation uses or develops AI systems, the clock is already running.

We will build the programme in 8 steps. Each step includes a template, a prompt for AI to help you complete it and a validation checklist. At the end, you will have a complete documentation package.

Step 1: AI systems inventory

You cannot comply with what you do not know. The first step is to identify ALL AI systems your organisation uses, develops, imports or distributes. Not just the obvious ones (the customer service chatbot, the scoring system). Also the invisible ones: the email spam filter, the intelligent spell checker, Excel suggestions, tools employees use on their own without IT knowing (shadow AI).

Inventory template

For each AI system identified, document:

• System ID: unique code (e.g. AI-001, AI-002).
• Name and version: commercial name, version, provider.
• Description: what the system does in 2-3 lines.
• Purpose: what it is used for in your organisation specifically.
• Organisation's role: deployer (user), provider (developer), importer, distributor.
• Responsible area/department: who manages it internally.
• Data processed: type of data (personal, sensitive, public), volume, source.
• Affected persons: who receives the system's decisions or outputs (employees, customers, citizens).
• Level of automation: fully automated decision, human decision assistance, content generation.
• Integration: what other systems it interacts with.
• Deployment date: when it was put into use.
• Contract/licence: reference to the contract with the provider.

Prompt for shadow AI discovery

Act as an AI systems auditor. I will describe my organisation's
departments and functions. For each one, identify the AI systems
that are probably in use, including those the department might be
using without formal authorisation (shadow AI).

Organisation: [sector, size, number of employees]

Departments:
1. [Department 1]: main functions, known tools
2. [Department 2]: main functions, known tools
[...]

For each department, identify:
A) FORMAL AI SYSTEMS (contracted, known):
   - Probable system name
   - Category (chatbot, scoring, recommendation, generation, etc.)
   - Estimated risk according to the AI Act

B) SHADOW AI (probable unauthorised use):
   - Generative AI tools used via browser (ChatGPT, Claude, etc.)
   - AI plugins in existing tools (Copilot in Office, etc.)
   - Mobile AI apps employees might use for work
   - Freemium AI services for specific tasks

C) SHADOW AI RISK:
   - Corporate data that could be flowing to external APIs
   - Confidentiality risk
   - Compliance risk

Generate a complete inventory using the indicated template format.

Step 2: Risk classification

With the complete inventory, the next step is to classify each system according to AI Act categories: unacceptable risk (prohibited), high-risk, limited risk or minimal risk. This classification determines which obligations apply.

Decision tree for classification

Follow this tree for each system in the inventory:

1. Question 1: Is the system on the list of prohibited practices (Art. 5)? Subliminal manipulation, exploitation of vulnerabilities, social scoring, real-time biometric identification in public spaces (with exceptions). If the answer is YES: the system is PROHIBITED. You must withdraw it.
2. Question 2: Is the system a safety component of a regulated product or is it in Annex III? Annex III lists the categories: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services (credit, insurance, public services), law enforcement, migration and asylum, administration of justice. If the answer is YES: the system is HIGH-RISK.
3. Question 3: Does the system interact with persons, generate synthetic content or biometrically categorise? If the answer is YES: the system is LIMITED RISK (transparency obligations).
4. If it does not fit any of the above: MINIMAL RISK. No specific obligations (voluntary codes of conduct are recommended).

Classify these AI systems according to the AI Act:

[Paste inventory list from Step 1 with: ID, name, description,
purpose, data processed, affected persons]

For each system:
1. CLASSIFICATION: Prohibited / High-Risk / Limited Risk / Minimal Risk
2. JUSTIFICATION: which AI Act article/annex applies and why
3. EXCEPTIONS: is any exception applicable?
4. CONFIDENCE: HIGH / MEDIUM / LOW (in the classification)
   - If LOW: what additional information do I need to decide?
5. DERIVED OBLIGATIONS: list of applicable requirements

NOTE: For systems on the boundary between categories, indicate both
options and recommend the more conservative one (classify upwards).

Generate a summary table: [ID | System | Classification | Key obligations]

Borderline cases

Most systems are not easy to classify. Some typical cases that generate doubt:

• Customer service chatbot: if it only answers FAQs, it is limited risk (transparency). If it makes decisions on complaints or automatically refunds money, it could be high-risk (access to essential services).
• HR system with AI: if it filters CVs or ranks candidates, it is high-risk (employment). If it only helps draft the job posting, it is minimal risk.
• General-purpose generative AI (GPT-4, Claude): as a general-purpose AI model (GPAI), it has specific obligations under Title V of the AI Act. But as a deployer, your obligations depend on what you use it for.
• Cybersecurity tools with AI: if they analyse threats and generate alerts, minimal risk. If they make automated blocking decisions that affect persons, they could be high-risk.

Step 3: Gap analysis

Now you know which systems you have and what category they fall in. The gap analysis compares your current state against the AI Act requirements for each category. It is the diagnosis that tells you exactly what is missing.

Requirements for high-risk systems (Title III, Chapter 2)

For each system classified as high-risk, assess compliance with these requirements:

1. Risk management system (Art. 9): does a continuous process of identifying, assessing and mitigating the system's risks exist?
2. Data governance (Art. 10): do the training data meet quality, representativeness and error-free criteria? Are they documented?
3. Technical documentation (Art. 11): does technical documentation exist that allows assessing the system's conformity?
4. Automatic logging (Art. 12): does the system generate logs that enable traceability of its operation?
5. Transparency and information (Art. 13): is sufficient information provided to deployers so they understand and correctly use the system?
6. Human oversight (Art. 14): does the system allow effective human oversight? Do the people who oversee it have the necessary competencies?
7. Accuracy, robustness and cybersecurity (Art. 15): does the system have adequate levels of accuracy, is it robust against errors and attacks, and is it protected?
8. Quality management system (Art. 17): does a QMS exist that covers the AI system?
9. Conformity assessment (Art. 43): has the applicable conformity assessment been carried out (or planned)?
10. Registration in the EU database (Art. 49): is the system registered (or to be registered) in the public database?

Perform an AI Act gap analysis for this high-risk system:

System: [ID, name, description, classification]
Current state:
- Technical documentation: [exists? what does it contain?]
- Training data: [documented? quality verified?]
- Logs: [does the system generate logs? what do they record?]
- Human oversight: [how is it supervised? by whom?]
- Risk management: [does a process exist? is it documented?]
- Cybersecurity: [assessments performed?]
- Conformity assessment: [performed? planned?]

For each AI Act requirement (Arts. 9-15, 17, 43, 49):
1. STATUS: COMPLIANT / PARTIAL / NON-COMPLIANT / NOT ASSESSED
2. EVIDENCE: what we have that demonstrates compliance
3. GAP: what is exactly missing
4. EFFORT: LOW (days) / MEDIUM (weeks) / HIGH (months)
5. PRIORITY: CRITICAL / HIGH / MEDIUM / LOW
6. SUGGESTED RESPONSIBLE: [role]

Generate:
- Gap summary table by requirement
- Top 5 critical gaps with action plan
- Total effort estimate in person-hours

Step 4: Compliance roadmap

With the gap analysis complete, you need an action plan with deadlines. The AI Act has phased application dates. Your roadmap must align with those dates.

Key AI Act dates

• 2 February 2025: application of prohibitions (Art. 5). If you have prohibited systems, you should have already withdrawn them.
• 2 August 2025: obligations for GPAI models (Title V). Affects providers of general-purpose AI models.
• 2 August 2026: application of requirements for high-risk systems (Title III). This is the critical date for most organisations.
• 2 August 2027: application of requirements for Annex I high-risk systems (products regulated by EU harmonisation legislation).

Roadmap template

Generate an AI Act compliance roadmap for my organisation:

CONTEXT:
- Number of AI systems: [total from inventory]
- High-risk systems: [number]
- Limited risk systems: [number]
- Critical gaps identified: [list from step 3]
- Available resources: [team, budget]
- Target date: August 2026 (high-risk deadline)

GENERATE A ROADMAP IN 4 PHASES:

PHASE 1 - FOUNDATIONS (months 1-3):
- Budget and team approval
- AI policy (draft and approval)
- Inventory finalised and validated
- Risk classification reviewed by legal
- Initial team training

PHASE 2 - CORE IMPLEMENTATION (months 4-8):
- Risk management system operational
- Technical documentation for each high-risk system
- Data governance: audit and remediation
- Human oversight mechanisms implemented
- Logging and traceability configured

PHASE 3 - DOCUMENTATION AND PROCESSES (months 9-11):
- DPIAs updated for each system
- Conformity assessment (internal or external)
- Registration in the EU database
- Quality management system (QMS) adapted
- Incident procedures
- Contracts with providers updated

PHASE 4 - VERIFICATION (month 12):
- Full internal audit
- Inspection simulation
- Findings remediation
- Status report to management committee

For each task: responsible, deadline, dependencies, deliverable.
Format: simplified Gantt table.

Step 5: Documentation package

The AI Act is, to a large extent, a documentation law. Requirements demand that you demonstrate compliance through specific documents. This step guides you in creating each one.

Mandatory documents for high-risk systems

1. Technical documentation (Art. 11 + Annex IV): general description of the system, design and development elements, training data, validation and testing, performance metrics, description of human oversight, risk assessment, quality management system.
2. Data Protection Impact Assessment (DPIA): mandatory when the system processes personal data and may generate high risk to rights and freedoms (Art. 35 GDPR). The AI Act DPIA is broader than the GDPR one: it includes fundamental rights beyond privacy.
3. Declaration of conformity (Art. 47): document signed by the provider declaring that the system complies with the AI Act.
4. Instructions for use (Art. 13): manual enabling the deployer to understand the system's capabilities, limitations and correct use.
5. Activity logs: automatic system records enabling traceability.

Prompt for technical documentation

Generate the technical documentation structure from Annex IV of the
AI Act for this AI system:

System: [name, version, provider/developer]
Classification: High-Risk - [Annex III category]
Purpose: [detailed description]

Generate the document with these sections (per Annex IV):

1. GENERAL DESCRIPTION:
   - Intended purpose of the system
   - Previous software/hardware versions
   - Forms of interaction with other systems

2. DETAILED DESCRIPTION:
   - Development methods and steps
   - Design specifications (general logic, algorithms)
   - System architecture
   - Computational requirements
   - Relevant design decisions

3. DATA:
   - Description of training, validation and test datasets
   - Sources and collection methods
   - Relevant characteristics, known potential biases
   - Data governance measures applied

4. PERFORMANCE:
   - Performance metrics
   - Declared accuracy levels
   - Validation test results
   - Performance with respect to specific groups

5. HUMAN OVERSIGHT:
   - Oversight measures implemented
   - Required human operator capabilities

6. RISK MANAGEMENT:
   - Risk management process applied
   - Identified risks and mitigation measures
   - Accepted residual risks

7. CHANGES DURING THE LIFECYCLE:
   - Record of substantial modifications
   - Version control

For each section, indicate:
- Required content
- Where to obtain the information (provider, internal team, tests)
- [PENDING] if additional work is needed

Prompt for extended DPIA (AI Act + GDPR)

Generate an extended DPIA covering GDPR + AI Act for this system:

System: [description]
Personal data processed: [types, data subject categories, volume]
Legal basis for processing: [consent, legitimate interest, etc.]

DPIA STRUCTURE:

1. DESCRIPTION OF THE PROCESSING:
   - Systematic description of processing operations
   - Purposes of the processing
   - Legitimate interests pursued

2. ASSESSMENT OF NECESSITY AND PROPORTIONALITY:
   - Is the use of AI necessary for this purpose?
   - Are there less intrusive alternatives?
   - Data minimisation principle

3. RISK ASSESSMENT FOR RIGHTS:
   A) GDPR risks:
      - Risk to privacy
      - Profiling risk
      - Automated decision-making risk (Art. 22)
   B) AI Act risks (fundamental rights):
      - Right to non-discrimination
      - Right to an effective remedy
      - Right to human dignity
      - Other affected fundamental rights

4. MITIGATION MEASURES:
   - Technical measures (anonymisation, encryption, access controls)
   - Organisational measures (training, policies, oversight)
   - Transparency measures (information to data subjects)
   - Human oversight mechanisms

5. CONSULTATION WITH DATA SUBJECTS (if applicable)

6. CONCLUSION AND ACTION PLAN

For each risk: likelihood (1-4), impact (1-4), resulting level,
mitigation measure, residual risk.

Step 6: Governance framework

Documentation without governance is worthless. You need an organisational framework that ensures the compliance programme lives beyond the initial project: that it is maintained, updated and executed day to day.

Recommended governance structure

• Level 1: AI Steering Committee. Composed of C-suite or equivalent. Meets quarterly. Approves AI strategy, budget and high-impact decisions (deploying a high-risk system, withdrawing a system, responding to a serious incident).
• Level 2: AI Ethics and Compliance Committee. Composed of legal, tech, business and an external member (see LG09). Meets monthly. Evaluates new systems, reviews incidents, issues guidelines, monitors compliance.
• Level 3: AI Compliance Officer. Dedicated person (or with partial dedication in smaller organisations). Manages the day-to-day: maintains the inventory, coordinates DPIAs, prepares conformity assessments, responds to internal queries.
• Level 4: System Owners. Each high-risk AI system has an identified owner. That person is responsible for operational compliance of their system: logs, human oversight, documentation updates.

Required internal policies

Generate the table of contents and executive summary for these
internal AI policies:

1. GENERAL AI POLICY:
   - Principles and values (aligned with AI Act + chosen ethical framework)
   - Scope (which systems, which people)
   - Roles and responsibilities
   - Approval for use of new AI systems
   - Prohibitions (which AI uses are not permitted)

2. GENERATIVE AI ACCEPTABLE USE POLICY:
   - Permitted and prohibited tools
   - Types of data that are NEVER entered into external AI
   - Approval process for new tools
   - User responsibilities
   - Mandatory human review before using output

3. AI RISK MANAGEMENT POLICY:
   - Risk assessment process
   - Classification according to the AI Act
   - Risk acceptance criteria
   - Escalation process

4. DATA GOVERNANCE POLICY FOR AI:
   - Data quality requirements
   - Dataset documentation
   - Bias detection and mitigation
   - Retention and deletion

5. AI INCIDENT PROCEDURE:
   - Definition of an AI incident
   - Reporting channels
   - Investigation and response
   - Notification to authorities (if applicable)
   - Lessons learned

6. CONFORMITY ASSESSMENT PROCEDURE:
   - When it is performed (before deployment, substantial changes)
   - Who performs it (internal vs external)
   - Documentation generated
   - Validity and renewal

For each policy: objective, scope, responsible, review frequency,
format (1-2 page summary + detailed annexes).

Step 7: Monitoring and audit plan

Compliance is not a project with an end date. It is a continuous process. The AI Act requires post-market monitoring for high-risk systems. You need a plan that ensures permanent vigilance.

Continuous monitoring

• Performance metrics: accuracy, recall, false positive/negative rate. Monitored in real time or periodically. Alerts if they fall below defined thresholds.
• Fairness metrics: the metrics chosen in the gap analysis (demographic parity, equalized odds, etc.), broken down by protected group. Monthly review.
• Data drift: is the data the system processes in production consistent with the training data? If the distribution changes significantly (data drift), performance may degrade.
• Model drift: does the model's performance degrade over time? ML models are not static: their accuracy can decline as the world changes.
• Incidents: record of all incidents related to the system (erroneous decisions, user complaints, technical failures).
• Human feedback: do human overseers report problems? How often do they intervene to correct the system?

Internal audit plan

Design an AI Act internal audit plan for my organisation:

Number of high-risk systems: [X]
Number of limited risk systems: [Y]
Audit team available: [people, dedication]

Generate:
1. ANNUAL AUDIT PROGRAMME:
   - Frequency by system type (high-risk: semi-annual,
     limited risk: annual)
   - Tentative calendar
   - Scope of each audit

2. AUDIT CHECKLIST PER SYSTEM:
   For each AI Act requirement:
   - Verification question
   - Evidence to request
   - Conformity criteria
   - Typical non-conformity

3. AUDIT PROCESS:
   - Planning (1 week before)
   - Execution (document review + interviews + testing)
   - Findings report
   - Corrective action plan
   - Closure follow-up

4. GOVERNANCE INDICATORS (KPIs):
   - % of systems inventoried
   - % of systems with complete technical documentation
   - % of gaps closed vs plan
   - Number of AI incidents
   - Average incident response time
   - % of staff trained on AI policy
   - Number of human oversight interventions

Step 8: Inspection readiness

National supervisory authorities for the AI Act (in Spain, the AESIA, the Spanish Agency for the Supervision of Artificial Intelligence) will have the capacity to inspect organisations that use or develop AI systems. Preparing for an inspection is not paranoia: it is diligence.

What an inspector may request

• Complete AI systems inventory.
• Risk classification and justification.
• Technical documentation for each high-risk system.
• DPIAs carried out.
• Evidence of human oversight (intervention logs).
• Performance and fairness metrics.
• Ethics/compliance committee minutes.
• Internal AI policies.
• Staff training records.
• Contracts with AI system providers.
• Incident records and corrective actions.
• Conformity assessments.
• Registration in the EU database.

Inspection readiness checklist

Generate an AI Act inspection readiness checklist:

Organisation: [sector, size, number of AI systems]
Role: [deployer / provider / both]

CHECKLIST STRUCTURE:

A) DOCUMENTATION READY TO DELIVER (within 48h):
   - [ ] Updated AI systems inventory
   - [ ] Risk classification with justification
   - [ ] Technical documentation per system
   - [ ] DPIAs
   - [ ] Declarations of conformity
   - [ ] General AI policy
   - [ ] Generative AI usage policy
   - [ ] Ethics committee minutes (last 12 months)
   - [ ] Training records
   - [ ] Incident register

B) PEOPLE PREPARED FOR INTERVIEW:
   - [ ] AI Compliance Officer: can explain the full programme
   - [ ] System Owners: can explain their system
   - [ ] DPO: can explain the DPIAs
   - [ ] CTO/CIO: can explain the technical architecture
   - [ ] Legal: can explain the risk classification

C) SYSTEMS READY FOR DEMONSTRATION:
   - [ ] Access to system logs
   - [ ] Performance metrics dashboard
   - [ ] Evidence of human oversight
   - [ ] Functional escalation process

D) SIMULATION:
   - [ ] Inspection simulation carried out (date: ___)
   - [ ] Simulation findings remediated
   - [ ] Team informed of the protocol

For each item: status (ready / in progress / pending),
responsible, deadline.

Final compliance checklist

Review this AI Act compliance programme as if you were an external auditor:

[Paste summary of the 8 deliverables]

Evaluate:
1. COMPLETENESS: is any deliverable or critical section missing?
2. CONSISTENCY: do the documents reference each other correctly?
3. REALISM: are the deadlines and resources feasible?
4. ROBUSTNESS: would the programme withstand an AESIA inspection?
5. IMPROVEMENTS: 3 recommendations to strengthen the programme

Maturity score: 1 (initial) to 5 (optimised)
Detail by area: inventory, classification, documentation,
governance, monitoring.

Conclusions and specialisation wrap-up