The Competencies: What You Need to Know, and How Deep

The function draws on four competency areas: regulatory, technical, assurance, and organisational.

Almost nobody holds all four at depth, and the expectation that you should is what stops people entering the field. The realistic shape is deep in one, functional in the other three, which is enough to do the work and to know when to bring in someone deeper.

Functional means something specific here: enough to ask the right question, understand the answer, and recognise when the answer is evasive. It does not mean enough to do the other person's job.

A privacy lawyer moving into this work does not need to train models. They need to know enough about how models are built and evaluated to ask why the disaggregated performance was not measured, and to recognise that a vendor's response was not an answer.

An engineer does not need to interpret statute. They need to know the Act's structure well enough to recognise that a proposed use has moved a system into an Annex III area, and to escalate before it ships rather than after.

The rest of this lesson sets out what functional means in each area, and how to get there from where you are.

The mistake here is trying to learn the Act the way one might learn a syllabus. It is long, it has been amended, and most of it will never apply to your organisation.

What functional regulatory competence actually requires is the structure.

The role definitions, provider and deployer, and the three ways a deployer becomes a provider. This determines who owes what and it is the most consequential thing to know cold.

The risk tiers and the two routes into the high-risk one, well enough to recognise an Annex III use case when someone describes a project in a meeting.

The Article 6(3) derogation and the profiling limit, because that is where the judgement lives and where the pressure to classify downward is applied.

The obligation sets for each role, at the level of knowing what exists rather than reciting it.

The timeline, as amended.

And where the neighbouring regimes attach: data protection, sector rules, product safety.

Beyond that, the skill is not recall but knowing where to look and when to ask a lawyer. Someone who can say this is an Annex III employment case, we may be relying on the derogation, and that is a documented assessment we need advice on has done the valuable part. The rest is research.

This is where non-technical entrants most often either overreach or give up. Neither is necessary, because the required depth is narrow and specific.

What you need. How a model is trained, at the level of training data producing a function that generalises, so that the connection between data and behaviour is intuitive. What an error rate is, and why aggregate accuracy conceals subgroup performance. Why a model's performance is conditional on its data distribution, which is the root of both drift and the deployer input-data duty. What a false positive and a false negative cost differently in a given decision, which is the question that determines the right metric. Roughly how generative systems differ from predictive ones, because their failure modes differ. And what automation bias is, since it undermines the control that mitigates everything else.

What you do not need. To train models, to read model architectures, to write code, or to evaluate a research paper.

A useful self-test: could you read a model evaluation report and identify what is missing from it? That is the operative skill, and it is closer to reading a financial statement critically than to accountancy.

The fastest route for a non-technical entrant is to sit with the team during an evaluation, and to ask what they measured, what they did not, and why.

The four competencies map onto four common entry professions, and each arrives holding one and needing three.

A privacy or data protection professional arrives with regulatory and assurance competence and the record-keeping habit, and needs the technical layer.

A lawyer arrives with regulatory depth and needs technical, assurance and often the organisational skill of operating without authority.

A data scientist or engineer arrives with the technical layer and the inventory knowledge nobody else has, and needs regulatory structure and assurance discipline.

A risk, audit or quality professional arrives with assurance and the management-system pattern, and needs regulatory specifics and technical depth.

None of these is a better starting point than the others. What differs is which gap to close first, and the answer is always the one that blocks the work in front of you.

Assurance is the least visible of the four and the one that separates a function that works from one that documents.

Its core question is not has a control been designed but is the control working, and answering it requires a specific discipline.

Evidence over assertion. A policy stating that humans review outputs is not evidence that they do. The override rate is. Someone with assurance training reaches for the number reflexively; someone without accepts the statement.

Testing the control, not the process. Whether the approval form was completed is a process question. Whether the system performs acceptably on the affected population is the question that matters, and only the second protects anyone.

Sampling. You cannot check everything, so check a defensible subset and know what the subset supports.

Independence. Assessing work you or your team produced is not assurance, whatever the report is titled.

And proportionality. Assurance effort should track consequence, or it consumes itself on low-stakes systems.

For entrants from legal or engineering, this is often the genuinely new discipline. The good news is that it transfers wholesale from internal audit, information security assurance, and quality management, and the patterns are well established elsewhere.

The fourth area appears in no job description and determines whether the other three produce anything.

The function usually has no authority. It cannot compel a team to classify a system, cannot stop a deployment unilaterally, and depends on people who have other priorities. Everything it achieves, it achieves through someone else's decision.

Four skills follow from that.

Translation. The same finding has to be expressed three ways: to an engineer as a measurement problem, to an executive as an exposure, to a lawyer as a position. Someone who can only speak one of these dialects is limited to one third of the organisation.

Proportionality in practice, meaning the judgement to let small things go. A function that objects to everything is routed around, and its objections to the thing that mattered arrive with no credibility left.

Curiosity that survives being tedious. Much of the work is asking people questions they consider unnecessary, repeatedly, pleasantly.

And the willingness to write down an uncomfortable conclusion. The value of the whole function reduces, at intervals, to whether someone recorded that a system was not adequately assessed when the pressure ran the other way.

That last one is not trainable in a course. It is worth knowing it is the job before taking it.

Certifications in this area are proliferating, and their value is real but narrower than their marketing.

What a certification does well. It gives an unfamiliar field a structure to learn against, which is genuinely useful when starting from outside. It signals commitment to a recruiter screening many applications. And in organisations that already recognise a body's credentials, typically privacy and security certifications, it maps onto an existing hiring pattern.

What it does not do. It does not establish competence, because the assessment tests knowledge of a framework rather than the judgement the work requires. It is not required by the AI Act, which mandates no qualification for anyone doing this. And it does not substitute for having done the work, which is what the next lesson is about.

Two cautions specific to this moment. Certification bodies moved quickly, so material can predate amendments, and a course teaching Article 4 as an obligation to ensure a sufficient level of AI literacy, or high-risk obligations landing on 2 August 2026, is out of date. Check what edition you are buying.

And be sceptical of anything implying that holding it makes an organisation compliant. Compliance is a property of the organisation's systems and records, not of its staff's credentials.

The reasonable position: worth it if you need structure or a signal, not worth it if you have access to real work instead.

More durable than any certification is familiarity with the standards the field is converging on, because they are what organisations will actually be assessed against.

ISO/IEC 42001 specifies an AI management system, following the same management-system pattern as ISO/IEC 27001 for information security and ISO 9001 for quality: policy, objectives, risk assessment, controls, internal audit, management review, continual improvement. Its structure maps closely onto the Article 17 quality management system, which makes it the most directly useful standard to know.

The NIST AI Risk Management Framework, though from a different jurisdiction, provides a widely used vocabulary organised around governing, mapping, measuring and managing AI risk. It is voluntary and it travels well, so it appears in organisations with no EU exposure at all.

And the European harmonised standards being developed to support the AI Act matter most of all, because conformity with a published harmonised standard creates a presumption of conformity with the requirements it covers. That work has been slower than the original timetable assumed, which contributed to the deadline extensions.

Knowing the management-system pattern is the transferable asset here. An organisation that already runs one has most of the scaffolding, and someone who can recognise that and extend it rather than building in parallel is worth considerably more than someone who cannot.

For someone starting from any of the four backgrounds, an order that builds usable competence rather than coverage.

First, the Act's structure: roles, tiers, the derogation, the obligation sets, the timeline. This is a few days of focused reading and it is the highest-return investment because it makes everything else legible.

Second, close your specific gap, not all three. A lawyer takes the technical layer, an engineer takes the regulatory structure, and each stops at functional rather than pursuing depth.

Third, learn the management-system pattern through ISO/IEC 42001, because it gives you the shape of what an organisation has to build and connects to structures many already run.

Fourth, and most valuable, do a real classification. Take one system in your own organisation and work it through end to end: what it does, who it affects, which area, which role, does the derogation apply, what is the reasoning. Write it up properly. The gap between reading about the derogation and having to justify one in writing is where the competence actually forms.

Fifth, only then consider a certification, if you need the signal.

The sequence deliberately puts doing before credentialing, because the artefacts that come out of step four are what the next lesson turns into evidence.