EU AI Act Product Audit Template: The PM's High-Risk AI Assessment

Step 0: Am I Actually In Scope?

Before running this template, confirm your product is within EU AI Act scope. The Act applies to providers placing AI systems on the EU market and deployers using AI systems in the EU, regardless of where the company is headquartered. A US company with EU customers using their AI product is in scope.

High-risk AI system categories under Annex III (enforceable August 2, 2026):

•Biometric identification and categorization

•Critical infrastructure management (energy, water, transport)

•Education and vocational training (student assessment, admissions)

•Employment, worker management, and recruitment

•Access to essential private and public services (credit scoring, insurance)

•Law enforcement and predictive policing

•Migration, asylum, and border control

•Administration of justice and democratic processes

•AI embedded in regulated products: medical devices, vehicles, machinery, aviation, toys

Not in scope (but still subject to transparency requirements):

•AI used purely for internal administrative tasks (no decision impact on external individuals)

•AI for scientific research and development

•Open-source general-purpose AI models (different rules apply under GPAI provisions)

•Military and national security applications (Article 2 exemption)

If you are in scope: run every section of this template. If you are not in scope for Annex III but your product uses AI in user-facing contexts in the EU, you still have transparency obligations (disclosure that AI is in use, certain explainability requirements). Use Sections 4 and 5 of this template as your minimum baseline.

Area 1: Risk Management System

Article 9 requires high-risk AI providers to establish, implement, document, and maintain a risk management system throughout the entire lifecycle of the AI system. This is a continuous process, not a one-time assessment.

Risk identification and classification

Have you identified the foreseeable risks your AI system poses to health, safety, and fundamental rights?

Are risks classified by likelihood and severity?

Have you considered misuse scenarios, not just intended use?

Risk mitigation measures

Is each identified risk addressed with a specific mitigation measure in the product?

Are residual risks documented and accepted by an accountable decision maker?

Have mitigations been verified in testing, not just assumed from design intent?

Lifecycle monitoring and update process

Is there a defined process for identifying new risks when the model is updated?

Does the risk register have an owner and a review cadence?

Is there a process for responding to user or third-party risk reports?

Area 2: Data Governance and Training Data Requirements

Article 10 sets data governance requirements for training, validation, and testing datasets used to develop high-risk AI systems. If you are using a third-party foundation model, you still need to understand and document the training data used for any fine-tuning or adaptation you performed.

Training data documentation

Is the source and provenance of your training data documented?

Are the data collection and labeling methodologies described?

Is there documentation of any known data limitations (coverage gaps, historical bias, domain restrictions)?

Bias assessment

Has the training data been assessed for characteristics that could introduce discrimination on protected grounds (race, gender, age, disability)?

Are there documented mitigations for identified biases?

Is bias monitoring in place for the model's production outputs?

Data quality and representativeness

Does the training data adequately represent the EU populations your system will make decisions about?

Is there a validation dataset that reflects real production distribution?

Are data quality standards documented and enforced in the data pipeline?

Build the Regulatory Fluency to Lead AI Products

The AI PM Masterclass covers how to navigate AI regulation, build compliance into product design, and lead cross-functional teams through regulatory requirements. Taught live by a Salesforce Sr. Director PM.

Areas 3 and 4: Technical Documentation and Transparency

Article 11 (technical documentation) and Article 13 (transparency and information provision to deployers) are the two most document-heavy requirements. PMs often underestimate the scope of what needs to be produced and maintained.

Technical documentation (Article 11, Annex IV)

General description of the AI system: intended purpose, version, interactions with other systems
Detailed description of components: software, hardware, and data requirements
Design specifications: training methodology, training data overview
Validation and testing procedures and results
Performance metrics including accuracy, robustness, and cybersecurity
EU Declaration of Conformity
CE marking documentation
EU database registration ID

Instructions for deployers (Article 13)

Identity and contact details of the provider
Characteristics, capabilities, and limitations of the AI system
Level of accuracy, robustness, and cybersecurity the system has been tested against
Expected lifetime and maintenance requirements
Description of all forms of human oversight: what decisions require human review
Expected inputs and output interpretation guidance
Known biases, risks, and mitigation recommendations for deployers

PM note on technical documentation ownership:

Legal and compliance teams typically own the Declaration of Conformity and registration. Engineering owns the technical architecture descriptions. The PM owns the intended purpose statement, the capability and limitation summary, and the human oversight design. These are product decisions before they are legal documents. Write them first, then have legal review them, not the other way around.

Areas 5, 6, and 7: Human Oversight, Accuracy, and Post-Market Monitoring

These three areas are where product design decisions most directly determine compliance outcomes. They cannot be retrofitted easily, which is why they need to be in the product spec from day one.

Human oversight (Article 14)

Override capability

High-risk AI systems must allow designated persons to intervene or stop the system in real time. Is there a UI mechanism for authorized users to override or halt AI decisions?

Understanding requirement

Oversight persons must be able to understand the AI system's capabilities and limitations. Is there documentation and training for the humans responsible for oversight?

Output interpretation support

Oversight persons must interpret outputs correctly. Does your product provide adequate context, confidence indicators, and explanation for each AI decision?

Accuracy and robustness (Article 15)

Performance metrics defined

Are accuracy, robustness, and cybersecurity metrics defined, measured, and documented for the specific use case the product is deployed in?

Error handling design

Is there a defined response to technical errors, including graceful degradation and fallback procedures? Are these tested explicitly?

Adversarial robustness tested

Has the system been tested against attempts to manipulate outputs through adversarial inputs? Is this documented?

Post-market monitoring (Article 72)

Monitoring plan in place

Is there a documented post-market monitoring plan covering what metrics are tracked, at what frequency, and what thresholds trigger a response?

Serious incident reporting

Is there a process for identifying and reporting serious incidents (harm to users) to national market surveillance authorities within 15 days?

Performance drift detection

Is there automated monitoring for model performance drift in production? Are there alerts when performance falls below the documented accuracy thresholds?

Running This Audit: Cadence and Ownership

The EU AI Act requires ongoing compliance, not a one-time conformity assessment. This template should be a living document, not a pre-launch checklist that gets filed and forgotten.

At product launch

•Complete all areas of this audit
•File technical documentation
•Register in EU AI database (if required)
•Affix CE marking
•Train oversight personnel

Quarterly

•Review post-market monitoring data
•Check for performance drift against documented thresholds
•Update risk register with any new identified risks
•Review user complaints and support escalations for compliance signals

On every significant update

•Re-run the technical documentation audit for changed components
•Re-assess risk register for changes introduced by the update
•Confirm human oversight mechanisms still function as designed
•Update accuracy and robustness documentation if model is retrained

Ownership map:

Product Manager

Intended purpose statement, capability/limitation summary, human oversight UX design, user-facing transparency, audit cadence coordination

Legal/Compliance

Declaration of Conformity, EU database registration, CE marking, regulator relationship management, serious incident reporting

Engineering/ML

Technical documentation (architecture, training data), accuracy and robustness testing, post-market monitoring infrastructure, adversarial testing

Data/Privacy

Training data documentation, bias assessment, data governance policy, GDPR intersection (if applicable)