AI governance: frameworks, programs and careers.

The EU AI Act, Regulation (EU) 2024/1689, is the first comprehensive horizontal law on artificial intelligence. It applies to organizations inside and outside the European Union when they place AI systems on the EU market or when the output of their systems is used in the EU. Its obligations apply in phases, and the timetable for some of them, notably for high-risk systems, was amended by a 2026 package of targeted changes known as the Digital Omnibus. Because these dates have moved, this guide does not repeat them: always check the latest consolidated text on EUR-Lex before planning against a deadline.

The EU is not alone. Data protection authorities already apply the GDPR and Brazil's LGPD to AI, US states are adopting AI-specific laws and Brazil is debating a dedicated AI bill. The common direction is clear: risk-based obligations, transparency towards affected people, human oversight and documented accountability.

Regulators are only one audience. Enterprise customers increasingly ask suppliers detailed questions about AI before signing: which models are used, where the data goes, whether customer data is used for training, how outputs are tested and who is notified when something goes wrong. A vendor that answers these questions with evidence wins deals; one that answers with a marketing page loses them or accepts unfavourable contract terms.

Before generative AI, most organizations had a handful of models built by specialists. Today, almost every employee can use a chatbot, a coding assistant or an AI feature embedded in office software. That moves AI risk from the data science team to the whole workforce: confidential data pasted into prompts, hallucinated facts in client documents, copyright questions over generated content, and new attack surfaces such as prompt injection. Governance has to reach people who will never train a model, which is why AI literacy has become a governance control in its own right.

The Act does not regulate "AI" as a technology. It regulates uses, and it scales obligations to the risk a use creates for health, safety and fundamental rights. The result is usually described as four tiers plus a separate regime for general-purpose models:

The tier depends on the intended purpose, not on the model: the same language model can power a minimal-risk drafting tool and a high-risk recruitment screener. That is why an AI inventory with a risk classification per use case is the foundation of compliance.

Obligations attach to roles, so the first legal question for any system is "what is our role?". The Act defines several operators:

• Provider: develops an AI system or general-purpose model, or has one developed, and places it on the market or puts it into service under its own name or trademark. Providers carry most high-risk obligations. See provider.
• Deployer: uses an AI system under its authority in a professional activity. A bank using a third-party credit model is a deployer. See deployer.
• Importer and distributor: bring systems from outside the EU or make them available on the market, with verification duties.
• Authorised representative: a person in the EU mandated by a non-EU provider.
• Product manufacturer: places a regulated product on the market with an AI system as a safety component.

Roles can shift. A deployer that puts its own name on a high-risk system, makes a substantial modification to it, or changes the intended purpose of a system so that it becomes high-risk, can be treated as a provider with the full set of provider obligations. Procurement and product teams need to understand this before they customize a vendor tool for a sensitive use.

Article 5 lists AI practices that are banned because their risk to fundamental rights is considered unacceptable. In summary, it prohibits AI systems that:

• use subliminal, manipulative or deceptive techniques that materially distort behaviour and cause or are likely to cause significant harm;
• exploit vulnerabilities linked to age, disability or a specific social or economic situation, with the same effect;
• evaluate or classify people based on social behaviour or personal characteristics in ways that lead to unjustified or disproportionate detrimental treatment (social scoring);
• assess the risk that a person will commit a crime based solely on profiling or personality traits;
• build or expand facial recognition databases through untargeted scraping of images from the internet or CCTV;
• infer emotions in the workplace or in education institutions, except for medical or safety reasons;
• categorize people by biometric data to infer sensitive attributes such as race, political opinions, trade union membership, religious beliefs or sexual orientation, with limited exceptions;
• perform real-time remote biometric identification in publicly accessible spaces for law enforcement, except in narrowly defined and authorised situations.

A system is high-risk in two situations: when it is a safety component of, or itself, a product covered by EU harmonisation legislation listed in Annex I (machinery, medical devices, toys, vehicles and others) that requires third-party conformity assessment; or when it falls into one of the use-case areas of Annex III. Those areas are biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including credit scoring and certain insurance pricing), law enforcement, migration and border control, and the administration of justice and democratic processes.

An Annex III system may escape the high-risk label if it does not pose a significant risk, for example because it only performs a narrow procedural task or improves the result of a completed human activity. The provider must document that assessment, and systems that profile natural persons remain high-risk. Providers of high-risk systems must, among other things:

• run a risk management system across the life cycle (Article 9);
• apply data governance to training, validation and testing data, including examination for possible biases (Article 10);
• draw up technical documentation (Article 11 and Annex IV) and enable automatic logging of events (Article 12);
• provide clear instructions for use to deployers (Article 13);
• design the system for effective human oversight (Article 14);
• achieve appropriate accuracy, robustness and cybersecurity (Article 15);
• operate a quality management system (Article 17);
• complete the conformity assessment, issue an EU declaration of conformity, affix the CE marking and register the system in the EU database;
• monitor the system after it is placed on the market and report serious incidents.

Deployers have a shorter but real list (Article 26): use the system according to its instructions, assign human oversight to people with the necessary competence, training and authority, ensure that input data under their control is relevant, monitor operation and report risks, keep the logs under their control, inform workers and their representatives before using high-risk AI at work, and inform people when a high-risk system makes or assists decisions about them. Public bodies, private entities providing public services and deployers of certain credit and insurance systems must also carry out a fundamental rights impact assessment (Article 27). Affected people gain a right to an explanation of certain decisions (Article 86).

Chapter V regulates general-purpose AI models: models trained on large amounts of data that can competently perform a wide range of tasks and be integrated into many downstream systems. Their providers must keep technical documentation, give downstream providers the information they need to understand the model and meet their own obligations, put in place a policy to comply with EU copyright law, and publish a sufficiently detailed summary of the content used for training, following a template from the AI Office.

Models classified as having systemic risk, a status presumed above a training-compute threshold that the Commission can update, carry additional duties: state-of-the-art model evaluation including adversarial testing (red teaming), assessment and mitigation of systemic risks, serious incident reporting and adequate cybersecurity. A voluntary General-Purpose AI Code of Practice offers one way to demonstrate compliance. For organizations that use rather than build these models, the consequence is downstream: ask for the documentation providers must now give.

Article 50 applies regardless of risk tier. Providers must design systems that interact with people so that those people know they are dealing with AI, unless it is obvious from context, and must mark synthetic audio, image, video and text in a machine-readable way. Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them. Deployers that generate or manipulate deepfakes must disclose that the content is artificial, and AI-generated text published to inform the public on matters of public interest must be disclosed unless it has undergone human review and someone holds editorial responsibility.

Article 4 asks providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other people dealing with AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context of use. Because the Act was amended in 2026, confirm the current wording of this article in the consolidated text. Either way, the governance logic is unchanged: people cannot oversee, question or safely use systems they do not understand.

The Act does not require any particular certificate. What organizations need is evidence that training is proportionate to roles and risks: who was trained, on what, when, and how understanding was checked. See the AI literacy section below.

Enforcement is shared. The AI Office inside the European Commission supervises general-purpose AI models; national market surveillance authorities supervise AI systems, coordinated through the European AI Board. Some countries created dedicated bodies, such as Spain's AESIA, and Member States must offer AI regulatory sandboxes.

Penalties are tiered. The highest fines, for prohibited practices, can reach EUR 35 million or 7% of worldwide annual turnover, whichever is higher, with lower ceilings for other infringements and proportionate treatment for SMEs. Application is phased: prohibitions, AI literacy and general-purpose model rules started earlier than most high-risk obligations, and the high-risk timetable was postponed by the 2026 amendments. Check the latest consolidated text on EUR-Lex for the dates that apply to you.

An AI management system applies the familiar plan, do, check, act cycle to AI. ISO/IEC 42001 uses the harmonized structure shared by ISO 27001, ISO 9001 and other management system standards, so organizations that already run one of them can integrate the AIMS instead of building it from scratch. Its main clauses require you to:

• understand the organization's context, its role regarding AI (developer, provider, user and so on) and the needs of interested parties, and define the scope of the AIMS (clause 4);
• secure leadership commitment, an AI policy and clear roles and responsibilities (clause 5);
• plan actions to address risks and opportunities, including an AI risk assessment, AI risk treatment and an AI system impact assessment, and set AI objectives (clause 6);
• provide resources, competence, awareness, communication and documented information (clause 7);
• operate the planned processes and controls (clause 8);
• monitor, measure, audit internally and hold management reviews (clause 9);
• correct nonconformities and improve continually (clause 10).

Annex A lists reference control objectives and controls grouped into themes: policies related to AI; internal organization; resources for AI systems; assessing the impacts of AI systems; the AI system life cycle; data for AI systems; information for interested parties; use of AI systems; and third-party and customer relationships. Annex B gives implementation guidance for each control, Annex C lists potential AI-related objectives and risk sources, and Annex D discusses use across domains and sectors.

As in ISO 27001, you do not apply every control blindly. Your risk treatment determines which controls are necessary, and you record the result in a Statement of Applicability (SoA): each Annex A control, whether it is included, why, and whether it is implemented, plus any additional controls you added. Auditors read the SoA as the bridge between your risks and your controls, so it should be traceable to the risk assessment rather than a copy of the annex with "yes" in every row.

This distinction causes a lot of confusion. ISO/IEC 42001 certification is granted to an organization's management system by a certification body, ideally one accredited for this scheme; ISO/IEC 42006 sets requirements for bodies that audit and certify AI management systems. The certificate says that the organization's AIMS, within a defined scope, conforms to the standard.

Personnel certification is a different thing: it attests that an individual has demonstrated specified knowledge or competence, usually through an exam. DPCert certifies people. Our exams cover ISO/IEC 42001 alongside the EU AI Act, NIST AI RMF and data protection law, and our scheme is designed with reference to ISO/IEC 17024, the standard for bodies certifying persons. A DPCert credential is not an ISO certificate and does not certify any organization; it is evidence of what the holder knows.

• ISO/IEC 22989: AI concepts and terminology, useful to align vocabulary across legal, risk and engineering teams.
• ISO/IEC 23894: guidance on AI risk management, adapting ISO 31000 to AI.
• ISO/IEC 42005: guidance on AI system impact assessment.
• ISO/IEC 42006: requirements for bodies auditing and certifying AI management systems.

Harmonised European standards that support the AI Act are being developed separately by CEN and CENELEC. When they are published and cited in the Official Journal, following them will give a presumption of conformity with the corresponding requirements; ISO/IEC 42001 alone does not.

In July 2024 NIST published NIST AI 600-1, the Generative AI Profile. It identifies risks that are unique to or amplified by generative AI, including confabulation (the NIST term for hallucination), information integrity, information security, data privacy, harmful bias and homogenization, intellectual property, dangerous or hateful content, human-AI configuration, value chain and component integration, and environmental impacts. For each it suggests actions mapped to the four functions. If your main exposure is employees and products using large language models, this profile is a practical place to start.

Under GDPR Article 35, a data protection impact assessment (DPIA) is required when processing is likely to result in a high risk to people's rights and freedoms, and the use of new technologies, systematic evaluation of personal aspects and large-scale processing of sensitive data are typical triggers. Many AI projects meet those triggers. In Brazil, the LGPD provides for the data protection impact report (RIPD), which the ANPD may require. Under the AI Act, certain deployers must also complete a fundamental rights impact assessment. They overlap heavily; a good program runs them as one coordinated assessment with shared evidence.

GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects, subject to exceptions with safeguards such as human intervention and the right to contest. Articles 13 to 15 require meaningful information about the logic involved. LGPD Article 20 gives data subjects the right to request review of decisions taken solely on the basis of automated processing that affect their interests, and to obtain information on the criteria and procedures used. These rules shape the design of automated decision-making: where a human sits in the loop, what that person can actually change, and what explanation the affected person receives.

Training and fine-tuning models on personal data raises questions that privacy teams must answer early: which lawful basis applies (often legitimate interest, which requires a documented balancing test), whether the original purpose of collection is compatible with training, how data subjects are informed, how data minimization and retention apply, and how rights such as access, objection and erasure work when data is embedded in a model. The European Data Protection Board addressed several of these questions in its Opinion 28/2024 on AI models, including when a model can be considered anonymous and the consequences of unlawful processing during development.

For organizations that only use third-party AI, the equivalent questions move into contracts: whether the provider uses your data to train its models, where data is processed, which sub-processors are involved and how international transfers are covered. These clauses are now a standard part of AI procurement.

Start with a short charter approved by senior leadership: why the program exists, its scope (which entities, which kinds of AI), who owns it and how it reports to the board. Name an accountable executive and a program lead, and decide whether you need a cross-functional AI committee. Write a simple RACI that covers legal, privacy, security, risk, data science, engineering, procurement, HR and the business owners of each use case. Many organizations align this with the three lines model: business owners in the first line, risk and compliance in the second, internal audit in the third.

You cannot govern what you cannot see. Build an AI inventory that records, for each system or use case: its purpose, owner, users and affected people, the model and vendor, the data used, the decisions it influences, your legal role (provider or deployer), the risk classification and the status of required assessments. Include AI features inside SaaS tools and employee use of public generative AI services, not just in-house models. Give each entry an owner and a review date so the register stays current.

Define a classification scheme that maps each use case to a risk level and to the review it needs. Combine legal triggers (EU AI Act tiers, GDPR automated decisions, sector rules) with organizational criteria (impact on people, scale, autonomy, reversibility, reputational exposure). Keep it short enough that a business owner can complete it in fifteen minutes. The output determines the path: low-risk uses get a light check, high-risk uses get a full impact assessment, testing plan and sign-off, and prohibited uses are stopped.

A small set of policies covers most needs:

• an AI policy that states principles, scope, roles and the review process;
• an acceptable use policy for employees using generative AI, saying which tools are approved, which data may never be entered and how outputs must be checked;
• an AI procurement standard with due diligence questions and contract clauses;
• a model and system development standard covering documentation such as model cards, testing and release criteria;
• an AI incident procedure linked to existing security and privacy incident processes.

Put a gate before deployment, proportionate to risk. For high-risk cases the gate should require an impact assessment (combining privacy, fundamental rights and AI-specific risks), a test plan with results against agreed thresholds, a human oversight design, a transparency plan for affected people and named sign-off. Record the decision and its conditions. The gate should also apply to significant changes, such as a new model version, a new data source or a new purpose.

After deployment, monitor performance, drift, complaints and overrides. Model drift and changes in the population a model serves can quietly turn a well-tested system into a harmful one. Report simple program metrics to leadership (inventory classified, assessments completed, open findings, incidents, training coverage) and use a maturity model to set yearly targets.

An AI impact assessment asks who could be affected, how, how severely and how likely, and what will be done about it. Good assessments describe the system in plain language, identify affected groups (including people who never use the system directly), consider misuse and failure modes, and end with concrete mitigations and an owner for each. They are living documents, revisited when the system or its context changes.

Testing should be planned against the risks identified, not run as a generic checklist. For algorithmic bias, choose fairness metrics that fit the decision and the legal context, and test across relevant groups, accepting that different metrics can conflict. For security, include AI-specific threats such as data poisoning, model extraction and prompt injection. For generative systems, red teaming by people who try to make the system fail is essential, and should be repeated when models are updated.

Human oversight is easy to claim and hard to make real. A reviewer who sees hundreds of recommendations an hour, without the information or authority to disagree, is not oversight; it is automation bias with a signature. Effective oversight defines what the human checks, gives them the context and explainability they need, gives them the time and authority to override, and measures how often they do. If nobody ever overrides, investigate.

Define what counts as an AI incident (harmful output, discriminatory pattern, security compromise, serious malfunction, misuse) and route it through a process with triage, containment, root-cause analysis, notification where required and lessons learned. Connect it to existing processes: a prompt injection that leaks personal data is simultaneously a security incident, a personal data breach and an AI incident. Under the AI Act, providers of high-risk systems have serious incident reporting duties, and deployers must inform providers and authorities in defined situations.