compliance

Strict liability is worthless if the claimant cannot prove a defect they never saw. Articles 9 and 10 answer that with a disclosure order, three presumptions of defectiveness, a presumption of causation, and a rule turning complexity into the claimant's ally. This lesson works through the cascade, the three-year and ten-year clocks, and what a defendant should be able to produce.

The Directive builds a chain of liable operators so an injured person in the EU always has someone to sue. This lesson covers the manufacturer and component manufacturer, the importer and fulfilment service provider route, the distributor's one-month rule, online platforms, how a modification makes you a manufacturer, the heads of damage including data loss, and the exemptions.

A product is defective when it lacks the safety a person is entitled to expect. Article 7 turns that into circumstances a court weighs, several written for software: the ability to learn after release, interconnection, cybersecurity requirements, and recalls. This lesson works through the list, the rule that a later improvement is not an admission, and why compliance is not a defence.

Directive (EU) 2024/2853 replaces the 1985 regime and settles a forty-year argument by naming software a product. This lesson covers the new definition and why delivery method is irrelevant, why information is not a product, how components and related services extend the net, where open source sits, and why liability cannot be disclaimed by contract.

Meeting the essential requirements is not the same as being able to show it. This lesson covers the Annex VIII modules and which one each tier allows, the harmonised-standards lever that keeps class I self-assessable, the public-documentation route open to open-source manufacturers, what Annex VII must contain, when a modification restarts the assessment, and the three penalty tiers.

Article 14 is the first Cyber Resilience Act duty to bite, and it reaches products already on the market. This lesson covers the two narrow triggers, who receives a report and through which platform, what each of the three stages must contain, the separate duty to tell users, where the clock starts and why that is the hard part, and how the cascade compares with NIS2, GDPR and DORA.

Annex I is two lists doing different jobs: thirteen properties the product must have, and eight things the manufacturer must keep doing. This lesson works through both, including the secure-by-default and automatic-update rules, what the software bill of materials clause actually demands, the five-year support period floor and the ten-year shelf life on each update, and what must reach the user.

Regulation (EU) 2024/2847 puts software and connected hardware under product safety law, with a CE mark for cybersecurity. This lesson sets the scope: what counts as a product with digital elements, why a cloud backend can be part of one, what sector law carves out, where open source and stewards sit, the four risk tiers from Annex III and IV, and how a reseller becomes a manufacturer.

Competition law was built to catch people agreeing in rooms. What happens when the coordination has no agreement, no communication, and no human intent, and how regulators are responding anyway.

The practical middle ground: knowing what data you actually have and reducing it, securing devices and home working without a device management budget, and answering the security questionnaires customers increasingly send to their small suppliers.

Being small exempts you from very little. This lesson covers the obligations a one-person business still carries: honest advertising after the FTC's AI enforcement sweep, fake reviews, telling customers when they are talking to a bot, data protection, and the judgement about what to keep human when nobody is making you.

The professional standards side: Circular 230 diligence and what it demands of a tool user, preparer penalties and where the exposure actually sits, why the tax practitioner privilege is narrower than most people assume, confidentiality of client data, and what remains valuable when research gets fast.

Tax work divides into compliance, advisory, controversy and planning, and AI touches them very differently. This lesson maps the split, then covers the authority hierarchy that governs every tax position, and why the regulation defining substantial authority excludes exactly the kind of output a model produces.

Running AI inside a regulated advisory practice: keeping tools within the firm's capture and supervision system, the confidentiality problem, what you may and may not say about your own AI use after the SEC's first enforcement actions, and the parts of the job a client structurally cannot get elsewhere.

The four workflows that recover the most advisor time: preparing for a review, capturing and documenting the meeting, producing client-ready written output, and digesting research. What each needs as input, where the Marketing Rule engages, and the review that has to happen before anything reaches a client.

Financial advice divides into gathering, analysis, recommendation, communication and administration, and AI compresses them very unevenly. This lesson separates them, explains why the recommendation itself sits behind a fiduciary or suitability duty, and covers the recordkeeping regime that makes this profession unusual.

Marketing's usual metrics cannot answer whether AI helped, because output volume rose and attribution is already hard. This lesson covers what to measure instead, the brand and legal risks that concentrate in this function, disclosure norms with clients and audiences, and the honest reckoning on which claimed gains survive scrutiny.

The obligations become concrete in three places: what you ask a vendor before buying, what you measure on your own applicants, and what you owe the person a system decided about. This lesson covers all three, plus the AI literacy duty as it applies to recruiters, and the questions worth asking before adopting anything.

Controls only work if a team meets them inside their normal process at a point where answers can still change the design. This lesson covers the three gates, writing a checklist that produces decisions rather than ticks, model and system cards, and giving someone the authority to stop a launch.

Almost every organisation has AI principles and almost none can point to a shipping decision they changed. This lesson covers why abstract commitments fail to bind, the specific gap between a value and a decision rule, ethics washing, and what a principle needs before it can affect anything.

Validation was built for models that produce a number, not for systems that produce prose. This lesson covers conceptual soundness, outcomes analysis and ongoing monitoring applied to modern AI, what changes for generative systems, the pre-deployment evidence pack, and how to document a position when no framework covers your system.

Human oversight is the control regulators lean on hardest and the one most often decorative. This lesson covers the four conditions that make it real, how to evidence each rather than assert it, the override rate as the diagnostic, and the audit trail needed to reconstruct a single decision eighteen months later.

Regulated deployment is judged on evidence, not intent. This lesson covers the assurance vocabulary supervisors already use: three lines of defence, effective challenge, independent validation, and the model risk management tradition, including the 2026 shift from SR 11-7 to SR 26-2 and the gap it deliberately leaves.

AI governance sits at the intersection of four competency areas, and almost nobody arrives holding all of them. This lesson sets out what each requires and how deep it must go: regulatory literacy, enough technical understanding to ask the right questions, assurance discipline, and the organisational skill the function runs on. It closes on certifications and what they are worth.

AI governance is a body of work before it is a job title, and most of it is done by people whose title says something else. This lesson sets out what the work consists of, how it splits across legal, risk, data protection and engineering, why a dedicated role appears at some scales and not others, and what the data protection officer precedent does and does not tell you.

Nobody hires for AI governance on the strength of a certificate. This lesson covers what to actually produce: the four artefacts that demonstrate competence, how to build them from work already available inside your current job, routes in from each adjacent profession, what the first ninety days look like, and an honest account of the parts of this work that are unpleasant.

AI procurement fails at the scoping stage, before any vendor is contacted. This lesson covers what makes an AI purchase different from ordinary software, the regulatory position you inherit from the seller, the questions that determine whether you become a provider yourself, how to specify a problem rather than a product, and the build-buy-or-do-nothing decision that should precede any shortlist.

A high-risk system reaches the market through a defined gate and stays there under continuing obligations. This lesson covers which conformity assessment procedure applies and when a notified body is involved, the declaration of conformity and CE marking, registration, substantial modification and reassessment, post-market monitoring, and serious incident reporting with its tiered deadlines.

Once a system is high-risk, Articles 8 to 15 set out what it must satisfy. This lesson works through them as engineering requirements rather than legal text: risk management as a continuous process, data governance including the 2026 change on special category data for bias detection, human oversight as a design property, accuracy and robustness, and transparency toward the deployer.

High-risk classification determines whether an organisation faces a substantial compliance programme or almost none. This lesson works through both routes: the Annex I product-safety route as narrowed in 2026, the eight Annex III use-case areas with the boundaries that get argued, and the Article 6(3) derogation, its conditions, and the assessment you must document to rely on it.

Governance that leaves no trace is indistinguishable from no governance. This lesson covers the documentation the AI Act requires: Annex IV technical documentation and its simplified SME forms, the quality management system, instructions for use, log retention, the fundamental rights impact assessment, registration, and how to make documentation a byproduct.

With an inventory in place, governance becomes a question of who decides what. This lesson covers the AI policy and what actually belongs in it, acceptable-use rules people can follow, decision rights mapped with RACI, the approval gate a new system passes through, an AI risk register with risks specific to these systems, and escalation that works when something goes wrong at eleven at night.

An AI governance framework that starts with a policy is built on nothing. This lesson covers the artefact everything else depends on: finding the AI systems you actually run, including the ones inside software nobody bought as AI, recording the fields that make the inventory usable, classifying each system, assigning real ownership, and binding the whole thing to triggers so it stays true.

There is no small-business exemption in the AI Act, but there is proportionality, and the 2026 Omnibus widened it. This lesson covers the simplifications for SMEs and the new small mid-cap category, the minimum defensible position for a deployer, how to sequence work against the amended deadlines, where GDPR work can be reused, and when you genuinely need a lawyer.

The AI Act sorts systems into four tiers by what they are used for, not by how sophisticated they are. This lesson covers prohibited practices, the two routes into the high-risk tier, the derogation that lets a listed system out, the transparency duties, and the timeline as amended by the 2026 Digital Omnibus: which dates moved, which did not, and how grandfathering works.

Before any obligation applies, two questions decide everything: is this an AI system under the Act, and what role does your organisation hold in relation to it? This lesson covers the definition of an AI system, the provider, deployer, importer and distributor roles, the acts that turn a deployer into a provider, the Act's reach beyond the EU, and what falls outside it entirely.

A designed program still has to be delivered, kept current as tools change, and documented well enough to show what you did. This lesson covers delivery formats and why attaching training to tool rollout beats annual campaigns, measurement that is useful rather than required, the records that constitute evidence, refresh triggers, and an honest account of what an AI literacy program cannot fix.

A single company-wide e-learning module satisfies nobody and teaches almost no one. This lesson turns the AI Act's own factors into a design method: inventory the AI systems actually in use, segment the population by what they do with them, and build a layered curriculum from a universal baseline through role-specific modules to high-risk operator training, with the content that belongs in each.

AI literacy has a legal definition in the EU AI Act, and the obligation attached to it changed in 2026. This lesson covers Article 3(56), the original Article 4 duty to ensure a sufficient level of literacy, how the Digital Omnibus reframed it as an obligation of effort rather than result, who is bound, which AI systems are in scope, and the adjacent duties that remain hard requirements.

A closer look at the banking workflows where AI delivers the most value. Learn how fraud models score transactions in real time and balance catching fraud against false alarms, how credit models predict repayment risk and expand or gate access to credit, and how AI monitors for money laundering, all with the human oversight and trade-offs that finance requires.

Governance must protect data as well as make it usable. Learn the control layer: how data classification by sensitivity drives every protection, how access control and least privilege limit exposure, how privacy by design reduces risk, how policies, standards, and procedures fit together, and why the best governance enables trusted self-service rather than locking data away.

Two internets, same technology, different shapes. Learn the operating requirements that platforms in China work under, from licensing and real-name accounts to filing recommendation algorithms with the regulator, how compliance became a core product function rather than a legal afterthought, why micro-dramas became a format with no Western equivalent, and what all the differences add up to.

The EU Digital Operational Resilience Act governs how financial entities withstand ICT disruptions, while Article 47 of the Swiss Banking Act is a criminal confidentiality duty over client data. This advanced lesson dissects both mechanisms, their exceptions, and why an institution can fall under both at once.

Map how the EU AI Act sorts systems into four risk tiers with matching duties, and how NIS2 sets a horizontal cybersecurity baseline with strict reporting clocks. Learn who each rule binds and how compliance is structured.

Learn how the EU GDPR and the revised Swiss Federal Act on Data Protection actually work: who they bind, when they apply across borders, the lawful bases and rights they create, and how enforcement and sanctions differ between the two regimes.

Responsible AI is a practice, not a slogan. This lesson covers the EU AI Act's four risk tiers and what each requires, model monitoring and drift detection, hallucination rates and human-in-the-loop design, guardrail KPIs, and how to run governance as a measured, auditable discipline rather than a compliance checkbox.

An honest look at the open-weights vs closed-API choice for LLMs in 2026 — covering data privacy, cost at scale, fine-tuning, latency, regulatory concerns, and the gap in raw capability per dollar.