What it is

An AI system is software that learns patterns from examples (its "training data") and then uses those patterns to produce an output: a prediction, a recommendation, a piece of content, or a decision. That is the whole idea. The one thing to hold onto from the start is that AI does not understand or know things the way a person does. It has seen a very large number of examples and produces whatever best fits the pattern. That is what makes it powerful, and it is also why it can be fluent, confident, and wrong at the same time.

Why it matters at work

AI is no longer a specialist tool. It is now built into email, search, office software, customer-service systems and hiring tools, so almost everyone operates AI whether or not they think of it that way. Understanding what it is (and is not) is the difference between using it as a fast, capable assistant and trusting it as an authority it was never designed to be. It is also the foundation of your organisation's legal duty to ensure staff have a sufficient level of AI literacy, which lesson 10 returns to.

AI vs ordinary software

Ordinary software follows exact instructions a person wrote: "if the invoice is over 1000, flag it." It does only what it was told, step by step, and it is predictable. AI is different: instead of being given the rules, it is shown thousands or millions of examples and works out the patterns itself. That is why AI can handle messy, human tasks that are almost impossible to write rules for, such as recognising a face, understanding a sentence, or drafting an email. It is also why AI is less predictable: nobody wrote the exact rule it is following, so it can behave in ways even its makers did not foresee.

The main types you will meet

Lessons 2 and 3 look closely at generative AI, because it is the kind most employees now use directly.

"Narrow" AI, not the science-fiction kind

Every AI tool in use today is narrow: it is skilled at one specific job and has no general understanding, common sense or awareness. A chatbot that writes beautifully cannot reliably add up a column of figures; an image generator knows nothing about your company. There is no human-like "general intelligence" inside these products, whatever the marketing suggests. Treat each tool as a specialist that is sharp in a narrow lane and unreliable outside it.

Why it can be confidently wrong

AI predicts the most plausible output, not the true one. When it does not know something, it will often produce a smooth, believable answer anyway (a "hallucination", covered in lesson 5). It has no built-in sense of whether it is right, so a made-up figure or an invented quote can look exactly as convincing as a correct one. The judgement it lacks is the judgement you provide.

You do not need to be technical to use AI well, but a simple picture of how it works prevents most mistakes before they happen. Every AI system has two phases: training (when it learns) and use (when you ask it to do something). This matters at work because it tells you exactly when to trust an AI tool and when to double-check it.

Training: learning from examples

During training, the system is shown an enormous number of examples (millions of documents, images, or past decisions) and gradually adjusts itself until it captures the patterns in them. Think of a trainee working through a huge archive of solved cases until they can handle new ones. Training happens once, in advance, and takes a great deal of computing power.

The "model" is the result

What training produces is called a model: a very large set of numbers that encode the patterns the system found. A model is not a copy of its training data, and it is not a search engine looking things up. It is closer to compressed experience. When you use the tool, it runs your input through the model and produces an output. (The technical word for this step is "inference"; you can simply think of it as "using" the AI.)

Why it matters: garbage in, garbage out

A model only knows what its training data showed it. If that data was incomplete, out of date, or carried human bias, the model learns those flaws and repeats them, often invisibly. This is why the quality and representativeness of the data matter so much, and why an AI can quietly be unfair (lesson 5). Good data in, useful patterns out; biased or thin data in, biased or thin results out. It is also why an AI tool built for one population or purpose may perform poorly for another.

Two limits to remember

• A knowledge cut-off. A model's built-in knowledge is frozen at the time it was trained. On its own it does not know recent events or your internal information, unless it has been specifically connected to live search or your own systems.
• The "black box". Because the system worked out its own patterns, even its builders often cannot fully explain why it produced one particular output. You usually cannot get a clean, trustworthy "reason" for a given answer, which matters whenever a decision needs to be justified to a customer, a colleague or a regulator.

Most of the AI people use day to day (ChatGPT, Microsoft Copilot, Gemini, Claude and the like) are large language models, or LLMs: AI systems trained on vast amounts of text to produce human-like writing. They deserve their own lesson, because they are now everywhere and because one quirk in how they work explains almost everything about using them safely.

The one trick: predicting the next word

An LLM was trained on a vast amount of text. When you give it a prompt, it produces an answer by repeatedly predicting the next word (really, the next small chunk of text, called a "token"), then the next, and the next, each time choosing what is most plausible given everything so far. That is the whole mechanism, done at enormous scale. It is astonishingly good at producing fluent, well-structured language. But notice what it is not doing: it is not looking up facts, checking a database, or reasoning the way a careful person does. It is predicting plausible text.

Prompts and context: what you put in shapes what you get

The text you give the AI (your prompt) steers everything that follows. A vague prompt gives a vague answer; a clear, specific prompt with the right background gives a far better one. The AI also only "sees" what is in the current conversation plus its training. This working memory is called the context window, and it is limited: in a very long chat, earlier details can effectively drop out of view, so do not assume it remembers everything you said.

What LLMs are good and bad at

It is not only text

The same idea powers tools that generate images, audio, video and code: they learned patterns from huge collections of examples and generate new material that fits. The same cautions apply, invented details, hidden bias, and possible copyright issues (lesson 5), plus specific concerns like realistic fake media of real people ("deep fakes", covered in lesson 7).

Getting better results, safely

Used well, AI is a genuine multiplier: fast, consistent, able to work at scale, and able to surface patterns a person would miss in a mountain of data. Using it where it helps is encouraged, not discouraged. This program is about using AI more, and more safely, not less. The skill to build is knowing when to lean on it and how much to check.

Where AI genuinely helps

• Drafting a first version (an email, a summary, a plan) that you then refine.
• Summarising, searching or comparing long documents.
• Sorting, tagging or prioritising large volumes of items.
• Explaining something unfamiliar, or rephrasing it for a different audience.
• Spotting patterns or anomalies for a human to review.

Across the business

The same handful of capabilities show up in almost every department:

Notice that a few of these (screening candidates, or decisions about money or people) are far higher-stakes than the rest. That difference is the most important judgement you will make.

The core habit: match your care to the stakes

The single most useful habit in this entire program is to judge the stakes of the decision the AI touches, and set your level of checking to match. The same tool deserves very different care depending on what rides on the output.

Good practice This "stakes ladder" is recommended practice that works for any tool. For the highest-stakes uses, it also connects to legal duties: the EU AI Act treats AI used for things like hiring or credit as "high-risk" and attaches specific obligations, which lessons 6 to 9 cover.

AI is useful precisely because it is fast, fluent and confident. Those same qualities are where the risks come from. Six come up again and again. For each, it helps to know what it is, why it happens, and what you do about it.

1. Hallucinations: confident, made-up answers

A hallucination is fluent output that is simply wrong: a wrong figure, a misread date, an invented quote, a fake source or reference. It happens because the tool predicts plausible content rather than retrieving facts (lesson 3), so a convincing-looking answer and a correct one feel identical.

What you do: verify anything factual before you rely on it, especially names, numbers, dates, quotes and citations. If it cannot be checked, do not present it as fact.

2. Bias and unfairness

AI learns from data about the past. Where that data reflected human bias or an unrepresentative sample, the model absorbs the pattern and repeats it at scale, usually without anyone intending it. The effect is strongest, and most harmful, in decisions about people: hiring, lending, access to services.

What you do: take special care with anything affecting people's opportunities or treatment; do not let an AI make such calls alone; and raise it if outputs seem to disadvantage a particular group. (Where AI is used for these decisions, fairness is also a legal requirement on the organisation, see lessons 6 to 9.)

3. Over-reliance and automation bias

Polished, authoritative-looking output invites you to accept it without thinking. The tendency to over-trust a confident machine is called automation bias, and it is the most common way AI mistakes reach the real world, through a person who did not check.

What you do: stay the decision-maker. Treat AI as a draft or a second opinion, never the final word, and treat confidence as a prompt to check, not a reason to relax.

4. Privacy and data leaks

Putting personal or confidential information into a tool can expose it, sometimes permanently, and anything you type may be stored or used to improve the service. "Shadow AI" (using unapproved personal tools for work data) is where most of this happens.

What you do: use only approved tools for personal or confidential data; when unsure, treat the answer as no and ask first. Lesson 9 covers this in full.

5. Security

AI opens new attack angles. A tool can be tricked by hidden instructions buried in content it reads, a technique called prompt injection (for example a web page or document that secretly tells the AI to ignore its rules or reveal data). AI-generated code can carry hidden flaws, and attackers use AI to write more convincing phishing.

What you do: treat AI output, and especially AI-written code, with the same scrutiny as anything from an unknown external source; never let an AI act on untrusted content without a human check.

6. Intellectual property and confidentiality

Generative AI learned from huge amounts of existing material, so its output can unintentionally resemble someone else's copyrighted work. And whatever you paste in may leave your control.

What you do: do not feed in other people's copyrighted material or your organisation's secrets unless the tool is approved for it, and review important generated content before treating it as original or publishing it.

The EU AI Act (Article 5) bans a short list of AI uses completely. Legal obligation These are not "high-risk, handle with care": they are not allowed at all, because they cause serious harm to people or their rights, and no business reason, consent or safeguard makes them lawful. In plain terms, the law prohibits AI that:

• Manipulates people using subliminal or deceptive techniques, distorting their behaviour in a harmful way.
• Exploits vulnerabilities (age, disability, or a difficult social or economic situation) to influence behaviour harmfully.
• Scores people socially: rating individuals by general behaviour or traits over time, leading to unfair treatment in unrelated situations.
• Predicts individual criminality from profiling or personality alone.
• Builds facial-recognition databases by untargeted scraping of images from the internet or CCTV.
• Recognises emotions in the workplace or in education (outside narrow safety or medical uses).
• Infers sensitive traits (such as race, political views, or sexual orientation) from biometric data.

A useful rule of thumb: these all involve using AI to manipulate, rank, judge or surveil people in ways that strip them of fair treatment or dignity.

Why it matters

Prohibited practices carry the Act's heaviest penalties for the organisation (up to 35 million euro or 7% of worldwide annual turnover), alongside the serious harm to the people affected and to the organisation's reputation. Getting one of these wrong is the single most costly AI mistake an organisation can make.

What you do

Good practice If a project, a supplier's pitch, or a "quick experiment" looks like any of the above, stop and raise it with your manager or AI governance owner before anything is built, bought or piloted. Flagging it early protects both you and the organisation. You are not expected to be the legal expert; you are expected to recognise the red flag and speak up.

People have a right to know when they are dealing with AI rather than a person, and when content was created or altered by AI. Legal obligation The EU AI Act (Article 50) requires this for providers and deployers in specific situations, and it is also simply honest practice that builds trust. Three situations matter most.

1. When people interact with AI

If someone is dealing with a chatbot or voice assistant, it must be made clear they are interacting with AI, not a human, unless that is already obvious from the context.

2. When content is AI-generated

Images, audio, video or text produced or meaningfully altered by AI should be labelled as such, so people are not misled. This matters most for anything published or shared outside the organisation.

3. Deep fakes and sensitive uses

Realistic AI-generated or altered media of real people (deep fakes), and systems that recognise emotions or categorise people by biometric data, carry specific disclosure duties. Treat these with particular care.

Transparency inside the organisation too

Good practice Being open internally counts as well: if a draft, analysis or figure came from AI, say so, so colleagues apply the right level of checking instead of assuming a human verified it. Quietly presenting AI output as your own finished work is how unchecked errors slip through.

Human oversight means a person stays able to understand what the AI is doing, check its output, override it, and stop it. Legal obligation For high-risk AI, the EU AI Act (Article 14) requires oversight to be built in; Good practice for everyday use it is simply sound judgement. Either way, the principle is the same: a human, not the tool, is accountable for the outcome.

Why it matters: automation bias

The most common AI failure is not a dramatic system error; it is a person accepting a confident output because it looks authoritative. This tendency is called automation bias. A screen that says "97% match", or a clean, formatted table, feels trustworthy even when it is wrong. The more polished the output, the more important it is to check. Treat confidence as a prompt to verify, not a reason to relax.

Before you act on AI output

When to escalate

Raise it with your manager or AI governance owner if an AI system produces something harmful, unfair or clearly wrong; if it behaves unexpectedly; or if you are being asked to rely on it for a decision you would not be comfortable owning yourself.

Using AI does not switch off data-protection law. Legal obligation The GDPR still applies in full to any personal data an AI tool touches, and confidential business or client information needs the same care. In practice, most everyday AI mistakes are data mistakes, so a few clear habits go a long way.

Know what counts as sensitive

• Personal data: anything that identifies a person (names, emails, IDs, photos, customer or employee records).
• Confidential information: contracts, financials, strategy, source code, anything not already public.
• Special-category data: health, biometrics, ethnicity, political or religious views and similar, which the GDPR protects more strictly.

The safe-data rules

A few security habits

Who to ask, and how to report a problem

Your organisation should have an AI governance owner (the person accountable for responsible AI use) and a clear way to report a concern or incident. If an AI system produces something harmful, unfair or unexpected, or if sensitive data may have been exposed, report it promptly. Early reporting keeps a small problem from becoming a large one, and it is always the right call.

You have now covered what AI is, how it works, where it helps, and what can go wrong. This final lesson pulls it together into something you can carry around in your head. The good news: being "AI literate" is not about being technical. It is about good judgement, applied with a few simple habits.

What good AI literacy looks like

Someone who uses AI well does not memorise rules. They have a feel for it:

• They know what AI is and is not: a powerful pattern tool, not a source of truth.
• They pick the right tool for the job, and an approved one for anything sensitive.
• They match their checking to the stakes, light for a rough draft, careful for anything about people, money or safety.
• They protect personal and confidential data, and stay transparent about AI use.
• They keep a human in charge of real decisions, and they speak up when something looks wrong.

Your "before you use AI" check

Good use vs poor use

In one line

Use AI freely where it helps, check it in proportion to the stakes, protect data, be open about it, and keep a person accountable for every real decision. If something feels off, ask. That is responsible AI use, and it is exactly what the law's AI-literacy duty is getting at.

Classification is the single most consequential technical decision you make under the Act. Everything downstream (which obligations apply, how much engineering work, the timeline, the cost) flows from it. Do it deliberately, at design time, and write down your reasoning. Work through this sequence in order.

Step 0. Determine your role

The same system creates different duties depending on your role. You are usually a provider if you develop the system and put it on the market under your name, and a deployer if you use someone else's system in your operations. You can be both (you build one system and use another). Note now: under Article 25 a deployer can become a provider by rebranding a system or substantially modifying it. Get your role wrong and the whole obligation set is wrong.

Step 1. Is it even an AI system? Art 3(1)

The definition has specific elements: a machine-based system that operates with some autonomy, may show adaptiveness, and, for explicit or implicit objectives, infers from its inputs how to generate outputs (predictions, content, recommendations, or decisions) that can influence environments. The decisive word is infers. A model that learns patterns from data infers; a plain deterministic script with hand-written if-then rules generally does not. Borderline cases (rules engines, simple statistics, optimisation) exist, so document your reasoning either way. If it is not an AI system, the Act does not classify it.

Step 2. Is it a prohibited practice? Art 5

Screen against the eight prohibitions before anything else (manipulation, exploitation of vulnerabilities, social scoring, individual crime prediction by profiling, untargeted face scraping, workplace/education emotion recognition, sensitive-trait biometric categorisation, and real-time remote biometric identification). If it lands here, there is no compliance path. Stop and redesign.

Step 3. Is it high-risk? Two routes

• Annex I route Art 6(1): the system is a safety component of a product covered by the EU product-safety laws in Annex I (medical devices, machinery, vehicles, etc.), and that product needs third-party conformity assessment. If both are true, it is high-risk.
• Annex III route Art 6(2): the system's intended purpose falls in one of the eight Annex III areas. Intended purpose, not the technology, decides this.

The Article 6(3) exception, and the profiling override

An Annex III system is not high-risk if it does not pose a significant risk of harm because it only: (a) performs a narrow procedural task; (b) improves the result of a completed human activity; (c) detects decision patterns without replacing or influencing the human assessment; or (d) performs a preparatory task. Critical exception: the derogation is unavailable if the system profiles natural persons. If you profile people in an Annex III area, you are high-risk, full stop. Claiming 6(3) is not free: you must document the assessment (Art 6(4)) and register the system (Art 49).

Step 4. Orthogonal checks

• Transparency Art 50: if it interacts with people or generates synthetic content, transparency duties apply regardless of tier.
• GPAI Ch V: if you provide a general-purpose model, that is a separate regime on top (see lesson T4).

Worked examples

For a high-risk system, Articles 9 to 15 set requirements that translate directly into engineering, MLOps and documentation work. Treat each as something you build and evidence, not a box to tick at the end. Below is what each one actually asks of your team.

Article 9, Risk management system

A continuous, iterative process over the whole lifecycle: identify reasonably foreseeable risks to health, safety and fundamental rights; estimate and evaluate them (including from misuse); adopt mitigations; test that residual risk is acceptable. It is a living register, not a one-time document.

In your work: keep a risk register linked to releases; re-run it when data, model or use changes; record the mitigations and the residual-risk decision, with an owner.

Article 10, Data and data governance

Training, validation and test data must be relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose, and examined for bias that could harm people or cause prohibited discrimination. Provenance and collection processes must be governed.

In your work: maintain dataset documentation (a datasheet per dataset: source, scope, labelling method, known gaps); test performance across relevant subgroups, not just in aggregate; track data lineage; justify representativeness for the population the system affects.

Article 11, Technical documentation Annex IV

Draw up, and keep current, the Annex IV file that demonstrates conformity: general description, development methods and design choices, system architecture, data requirements, monitoring and functioning, performance metrics, the risk-management system, lifecycle changes, standards applied, the declaration of conformity, and the post-market plan.

In your work: generate this from your existing engineering artefacts rather than writing it fresh; version it with the system. This is what the Vigilis Annex IV Dossier indexes and tracks.

Article 12, Record-keeping (logging)

The system must automatically log events over its lifetime to enable traceability of its functioning. Logs are retained (Article 19).

In your work: decide what to log (inputs, key outputs and scores, model and config version, human overrides, errors), protect logs from tampering, and set a retention period that meets the legal minimum.

Article 13, Transparency and instructions for use

The system must be transparent enough for deployers to interpret and use it correctly, accompanied by instructions for use covering capabilities, limitations, expected accuracy, the human-oversight measures, and input-data expectations.

In your work: write instructions for use as a real deliverable; be explicit about limitations and known failure modes, not just capabilities.

Article 14, Human oversight

Design the system so a person can understand its capabilities and limits, monitor operation, correctly interpret output, decide not to use it, override it, and stop it. Guard against automation bias (people over-trusting confident output).

In your work: choose an oversight pattern (human-in-the-loop for consequential decisions, human-on-the-loop for monitoring), surface confidence and uncertainty, provide a clear override and a stop control, and make the "why" of an output inspectable.

Article 15, Accuracy, robustness and cybersecurity

Declare appropriate accuracy metrics and levels for the intended purpose; be robust to errors, faults and inconsistencies, with fallback or fail-safe behaviour; and secure against AI-specific threats: data poisoning, model poisoning, adversarial/evasion inputs, and model or data confidentiality attacks.

In your work: publish the accuracy metrics you stand behind; test robustness (edge cases, drift, adversarial inputs); design graceful degradation; add AI-specific items to your threat model.

For a high-risk system the work spans three phases: prove conformity before market, monitor in use, and respond when something goes wrong. Each has concrete technical obligations.

Before market: conformity assessment Art 40–49

You demonstrate conformity through one of two routes (Article 43):

• Internal control (Annex VI): a self-assessment. This covers most Annex III high-risk systems.
• Notified body (Annex VII): a third-party assessment of your quality management system and technical documentation. Required for certain cases (for example some biometric systems).

Relying on harmonised standards (Art 40) or common specifications (Art 41) gives a presumption of conformity (Art 42), so track and adopt them as they publish. Then draw up the EU declaration of conformity (Art 47), affix CE marking (Art 48), and register the system in the EU database (Art 49, Annex VIII).

Testing before release

Validation is not just aggregate accuracy. Test:

• Performance by subgroup (fairness across the groups the system affects), not only overall.
• Robustness: edge cases, out-of-distribution inputs, data drift, and adversarial inputs.
• Failure modes and fallback: what happens when it is uncertain or wrong, and whether the fail-safe behaves.
• Oversight controls: that a human really can interpret, override and stop it.

In use: post-market monitoring Art 72

Run a documented post-market monitoring plan: actively and systematically collect and analyse performance data across the system's life, and feed findings back into the risk-management system (Art 9). This is a live process with an owner and a cadence, not a dashboard nobody reads.

When it goes wrong: serious incidents Art 73

A serious incident (a malfunction or use leading to death, serious harm to health, serious and irreversible disruption of critical infrastructure, breach of fundamental-rights obligations, or serious property/environmental harm) must be reported to the market-surveillance authority without undue delay and within strict deadlines after you become aware. Build the internal pipeline now so you can actually meet those deadlines: detection, triage, an owner, and a reporting path.

Change management Art 19, 20, 25

Keep the automatically generated logs (Art 19). Take corrective action and inform authorities and distributors on non-conformity (Art 20). And remember that a substantial modification can reset your provider obligations and require re-assessment (Art 25). Treat model retraining and material changes as compliance events, not silent deploys.

Most teams do not train foundation models, but almost all now build on top of them. Two situations need care: providing a general-purpose model, and integrating someone else's.

If you provide a general-purpose AI model Art 51–56

A general-purpose AI model (a broad model usable across many tasks, such as a large language model) sits under Chapter V, a separate regime from the risk tiers.

• All GPAI providers Art 53: maintain technical documentation (Annex XI), provide information to downstream providers who integrate the model (Annex XII), put in place an EU copyright policy, and publish a sufficiently detailed summary of the training content.
• Systemic-risk models Art 51, 55: models above the designation threshold (Annex XIII) add model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity protection.
• Codes of practice Art 56: the main route to demonstrate GPAI compliance while standards mature.

If you integrate a third-party model or system Art 25

The value-chain rules decide who carries which duty. The traps:

• You can become a provider (with the full provider obligation set) by putting your name or trademark on a high-risk system, by substantially modifying it, or by repurposing a non-high-risk system to a high-risk use.
• If you build a high-risk system on top of a GPAI model, you are entitled to the information the model provider must give you under Annex XII. Demand it, you need it for your own documentation.

What to secure from upstream

• The model or component's intended purpose, capabilities and limitations.
• The technical information you need to meet Articles 10 to 15 for your system.
• Contractual flow-down of relevant obligations and support for conformity.

The Act does not assign duties to "the company" in the abstract. It assigns them to defined roles, and to named people. A leader's first job is to work out which roles the organisation holds, and to make sure someone owns each duty.

Which role are you? Art 3, 16–27

Many organisations are both provider and deployer: you build one AI product and use others internally. Map every AI system to a role.

The trap that catches leaders: becoming a provider Art 25

You can quietly acquire the full provider obligation set without building anything, by: putting your brand on a third-party high-risk system; substantially modifying a system; or taking a general-purpose or non-high-risk system and repurposing it to a high-risk use. This matters commercially: white-labelling or heavily customising a vendor's AI can shift the heaviest duties onto you. Check this before signing.

The deployer duties people forget Art 26, 27

Even as a deployer you must use the system per its instructions, ensure human oversight, monitor it, keep logs, and inform affected people. And certain deployers (public bodies, and private providers of some essential services) must complete a fundamental rights impact assessment (Art 27) before putting a high-risk system into use.

Name the accountable people

"Everyone is responsible" means no one is. Assign:

• an AI governance owner, accountable for the organisation's compliance, with executive sponsorship;
• an oversight person for each high-risk use (Art 14), with the competence and the authority to override or stop the system;
• clear ownership of each duty (a simple RACI works): who is Responsible, Accountable, Consulted, Informed.

Meeting the Act is an organisational capability, not a project with an end date. Think of it as four layers that reinforce each other: policies set expectations, processes carry them out, roles own them, and records prove them. Here is what to stand up.

The components every organisation needs

• AI system inventory, with each system classified and mapped to a role. You cannot govern what you have not listed.
• An AI use policy setting the ground rules (approved tools, prohibited uses, escalation).
• AI literacy training (this program) with completion records, your direct Article 4 evidence.
• Incident and complaint handling, so issues are captured, escalated and, where serious, reported on time.

Additional layer for high-risk systems Art 9–49, 72

• a quality management system (Art 17) governing how you build and maintain them;
• risk management (Art 9), data governance (Art 10) and technical documentation (Art 11);
• human oversight (Art 14) and logging (Art 12, 19);
• conformity assessment (Art 43), declaration of conformity (Art 47), CE marking (Art 48), registration (Art 49);
• post-market monitoring (Art 72) and corrective action (Art 20).

A sensible maturity path

The case for taking this seriously has three parts: the fines, the wider risk, and, often the biggest, the commercial upside.

The fines Art 99–101

Each is "the higher of" the fixed sum or the percentage, except for SMEs and start-ups, where Article 99(6) applies the lower of the two. The amount is set on the Article 99(7) factors: gravity, intent or negligence, mitigation, cooperation, and size.

The wider risk

• Market access. Enterprise buyers and investors now ask about EU AI Act compliance in due diligence. A weak or missing answer stalls or loses the deal, long before any regulator is involved.
• Individual rights. People can lodge complaints (Art 85) and, for high-risk decisions, demand an explanation (Art 86). Poor practice becomes visible and disputable.
• Reputation. An AI failure that harms people, or a prohibited-practice story, is a brand event, not just a legal one.

The upside, which is the real point

A credible, documented compliance position is a sales asset. It answers the buyer's question immediately, shortens diligence, and signals a vendor that can be trusted with regulated use cases. For a company selling AI into the EU, "we are EU AI Act ready, and here is the evidence" is a differentiator that wins deals competitors lose. Treated well, compliance is a moat, not a cost centre.

What to track at board level

Knowing the duties is not the same as running a program that meets them. This lesson is the practical operating model: how to stand it up, how to buy AI safely, and how to keep it current.

A phased rollout

Buying and deploying third-party AI

Most organisations are deployers of other people's AI, so procurement is where a lot of risk enters. Before you deploy a vendor's system, require:

• the vendor's classification of the system and the reasoning;
• instructions for use, with capabilities, limitations and expected accuracy;
• evidence of conformity (declaration of conformity, CE marking, registration) for high-risk systems, and the technical information you need for your own oversight;
• contractual flow-down of obligations, support for your monitoring, and notice of substantial changes.

And remember the Article 25 trap from lesson L1: rebranding or substantially modifying a vendor's high-risk system can make you the provider. Decide that consciously, not by accident.

Continuous compliance

The law itself moves. The Digital Omnibus (Regulation (EU) 2026/1744) changed the timeline and added prohibitions after the base Act. Treat compliance as a standing capability: re-run your assessment when systems change and when the rules change, and keep documentation audit-ready rather than assembling it in a panic when a buyer or regulator asks.

AI, in plain terms

AI system. Software that learns patterns from examples (data) and uses them to generate outputs: predictions, recommendations, content or decisions. It does not understand meaning the way a person does. Lesson 1

Training. The one-off process of showing an AI system many examples so it learns the patterns in them. Lesson 2

Model. The result of training: a large set of learned patterns the tool uses to produce outputs. Not a database and not a search engine. Lesson 2

Inference. Using a trained model to produce an output from your input. In plain terms, "using" the AI. Lesson 2

Knowledge cut-off. The point in time a model's built-in knowledge is frozen. Without live access, it does not know anything more recent. Lesson 2

Generative AI. AI that creates new content, text, images, audio, video or code, rather than only sorting or scoring. Lessons 1, 3

Large language model (LLM). A generative AI trained on vast amounts of text that answers by predicting plausible next words. Examples: ChatGPT, Copilot, Gemini, Claude. Lesson 3

Prompt. The instruction or question you give an AI tool. Clearer, more specific prompts give better results. Lesson 3

Context window. The limited "working memory" an AI holds in a conversation. In long chats, earlier details can drop out of view. Lesson 3

Hallucination. Fluent AI output that is simply wrong or made up, a side effect of predicting plausible content rather than retrieving facts. Lessons 1, 3, 5

Bias. Systematic unfairness an AI learns from unrepresentative or prejudiced data, and then repeats at scale. Lessons 2, 5

Automation bias. The human tendency to over-trust confident, polished AI output and skip checking it. Lessons 5, 8

Prompt injection. A security attack where hidden instructions in content an AI reads trick it into ignoring its rules or leaking data. Lesson 5

Shadow AI. Using unapproved personal AI tools for work data, the most common cause of AI data incidents. Lessons 5, 9

Deep fake. Realistic AI-generated or altered media of a real person. Carries specific disclosure duties. Lesson 7

EU AI Act terms

EU AI Act. Regulation (EU) 2024/1689, the EU law that regulates AI by risk. It applies to organisations that provide or use AI affecting people in the EU.

AI literacy (Article 4). The requirement that staff, and others operating AI on an organisation's behalf, have enough understanding to use it responsibly. This program is how your organisation meets it.

Provider. Whoever develops an AI system and places it on the market under their own name. Carries the most obligations.

Deployer. Whoever uses an AI system under their own authority in their work. Fewer duties than a provider, but real ones: use as intended, keep oversight, monitor, inform affected people.

Risk tiers. The Act sorts AI by risk: prohibited (banned), high-risk (heavy obligations), limited (transparency only), and minimal (no specific duties).

Prohibited practice (Article 5). A use banned outright, for example social scoring or workplace emotion recognition. No exceptions and no compliance path.

High-risk. AI used in a sensitive area (such as employment, credit, education, biometrics or law enforcement) or as a safety component of a regulated product. Triggers the full obligation set.

Annex III. The Act's list of the high-risk use areas.

Transparency (Article 50). The duty to tell people when they are interacting with AI and to label AI-generated content.

Human oversight (Article 14). Keeping a person able to understand, check, override and stop a high-risk AI system.

GPAI (general-purpose AI model). A broad model (like an LLM) usable for many tasks. It has its own separate set of rules (Chapter V).

Conformity assessment & CE marking. The checks a high-risk system must pass before sale, and the CE mark that shows it did.

Post-market monitoring. Keeping watch over a high-risk system after it is in use, and reporting serious incidents.

FRIA (fundamental rights impact assessment). A check certain deployers must do before using a high-risk system, on how it could affect people's rights.