Dr.Walter KurzMBA, M.Sc.

Authority, access, budget, the standing to refuse and a route to escalate: what has to be granted for the role to exist.

• Difficulty

Board, statutory officers, process owners, technology and legal: what does not move to the officer.

• Difficulty

Reporting line, access to the accountable body, and the conflict created when the officer also owns delivery.

• Difficulty

The first ninety days: no register, no policy, no budget line, and systems already running.

• Difficulty

Forty people and no lawyer, against a group with three assurance functions.

• Difficulty

Asking for the budget and the people the apparatus needs, with a figure.

• Difficulty

The inventory: system, purpose, owner, supplier, users, affected groups, data, risk class, status.

• Difficulty

Embedded features and supplier-added AI, brought into scope.

• Difficulty

Wiring intake, procurement, security review and change management into the register so it survives a year.

• Difficulty

Turning principles into rules somebody can apply without asking the officer.

• Difficulty

Acceptable use, written in language people read.

• Difficulty

Thresholds, restricted uses, and uses the organisation will not make, translated from oversight intent into an operable taxonomy.

• Difficulty

Who must know what before they may propose, approve, operate or use.

• Difficulty

Who may decide what, at what risk level.

• Difficulty

Data, evaluation, law, security, oversight, benefit and exit as the evidence pack per decision.

• Difficulty

Designing a committee that decides rather than deliberates.

• Difficulty

Triage, fast lanes and a proportionate path for low-risk uses.

• Difficulty

Designing a path people use instead of going around the officer.

• Difficulty

Making a decision reconstructable by somebody who was not in the room.

• Difficulty

Bringing a running system back to the gate before it drifts out of its permission.

• Difficulty

Supplier changes, new features and scope creep after go-live.

• Difficulty

Detection, containment and correction, built before it is needed.

• Difficulty

Running an exercise and acting on what it exposes.

• Difficulty

Failure that arrives as complaints, appeals and quiet workarounds rather than as an alert.

• Difficulty

Who is told, by when, and by whom.

• Difficulty

Holding a position in front of the press and the people affected.

• Difficulty

Designing a route that actually reaches the people who were harmed.

• Difficulty

Channels for affected people and for staff, built before they are needed.

• Difficulty

Stopping something, and surviving having stopped it.

• Difficulty

Leaving a record that protects the organisation and the officer.

• Difficulty

Holding responsibility for a system somebody else runs, including a shared one.

• Difficulty

Supplying each function with what AI obliges it to hold, and noticing when an AI decision lands inside theirs.

• Difficulty

The same, for the systems that answer outward.

• Difficulty

Lines of defence, control testing and corrective action.

• Difficulty

Performance, incidents, drift, benefit and new obligations, reviewed on a rhythm.

• Difficulty

Assembling continuously so the pack already exists when it is asked for.

• Difficulty

Cadence, contents, and how to carry the bad news.

• Difficulty

Making an apparatus stick with people who did not ask for it.

• Difficulty

Regulation, suppliers, technology and incidents elsewhere, feeding the register.

• Difficulty

Putting the pieces together so the whole holds up when it is examined.

• Difficulty

Someone brings the officer a proposal that opens with a technology and a vendor, and never says what is currently going wrong. Everyone in the room nods, because it sounds like progress, and nobody can say what would be different afterwards.

• Difficulty

A proposal says it will "transform customer service" or "automate underwriting". The officer cannot tell what would actually change on a Tuesday, and neither can the people doing the work.

• Difficulty

The officer is asked whether an initiative is worth doing and finds themselves arguing about the technology, because nobody has said where the money or the advantage would actually appear.

• Difficulty

The programme is a year old and someone from finance has asked, reasonably, what it delivered. The pilot report says the system handles the task in four minutes. Nobody wrote down what it took before, nobody kept the old volumes, and the two people who would have known have moved on. The saving may be large. It is now unprovable.

• Difficulty

Two proposals arrive. One saves money on work the whole industry does. The other would let the firm do something competitors cannot. They are presented in the same format, with the same kind of number, and are treated as comparable.

• Difficulty

A vendor demonstration is impressive. The officer is asked whether this would give the firm an edge, and realises the same demonstration is being given to their competitors this week.

• Difficulty

The strategy rests on "our unique data". The officer asks to see it and finds four years of records with the important field filled in half the time, no rights to use it for this purpose, and nothing feeding back from operation.

• Difficulty

An investment case assumes a capability stays scarce for five years. The officer has watched the same capability go from a research demonstration to a checkbox in software they already pay for, twice.

• Difficulty

The business case is approved on a build figure. A year later the bill has grown with usage, nobody budgeted for it, and success has made the finances worse.

• Difficulty

The vendor quote is the number in the paper going to the board. It omits integration, evaluation, monitoring, support, retraining and the change effort, all of which land on the organisation. Two more that are always missing: somebody internally has to own this product, and somebody has to do the assurance and approval work.

• Difficulty

The system is 92 percent accurate and everyone is pleased. Then somebody asks how the reviewer is supposed to know which cases are in the 8 percent. If telling requires redoing the work, the review costs close to the full task rather than eight percent of it, and the saving was never there.

• Difficulty

The efficiency arrives exactly as promised. Within a year every competitor has it, prices have moved, and the customer has the benefit while the firm has the cost.

• Difficulty

The pilot worked. Twelve months later the tool is installed, the benefit case still shows the original figure, and half the team have gone back to the old way of doing it.

• Difficulty

A complete, professional, plausible AI proposal arrives with a decision expected this week. It is the officer's judgement that stands between it and the budget.

• Difficulty

Choosing means foregoing. A plan that rules nothing out has committed to nothing, and this is the sitting where a learner writes the sentence most AI strategies avoid.

• Difficulty

Turning a general wish to use AI into one sentence about how this organisation intends to win with it, and turning scattered pilots into a position.

• Difficulty

Reading the change one level up: what happens to the sector when everyone has the capability, and where that leaves this organisation.

• Difficulty

Turning a list of possible AI uses into a defensible order, on value, feasibility, data readiness, risk and reversibility.

• Difficulty

How much money, across how many bets, over what time: the proportions that turn a ranked list into a portfolio.

• Difficulty

The point where AI stops improving the existing business and starts altering the offering itself.

• Difficulty

Seat, usage, outcome, bundle or tier, and what each does to customer behaviour and to your own economics.

• Difficulty

Keeping an offering profitable when the cost of serving it rises with how much it is used.

• Difficulty

The sourcing decision taken as an argument about what has to be owned to hold a position, rather than as procurement.

• Difficulty

What the supplier owns after signature, and what it would cost to leave.

• Difficulty

Whether timing is decisive for a particular move, and what each posture costs.

• Difficulty

Writing a strategy that survives finding out which of its branches are foreclosed, restricted or expensive to defend.

• Difficulty

Signing a strategy before anyone knows the capability will reach the required quality: staging, thresholds and kill criteria.

• Difficulty

Producing the document itself: what an AI strategy contains and how the parts hold together.

• Difficulty

Holding the position under the four questions a board actually asks: what it costs, what it returns, what a competitor could do about it, and who carries the risk.

• Difficulty

The shift from running projects to running a function: what happens monthly, quarterly and annually, and who is in the room for each.

• Difficulty

Building the path AI requests arrive through, and finding what is already running that nobody asked about.

• Difficulty

The recurring decision: what gets funded this cycle, what continues, what stops, what scales.

• Difficulty

Budgeting a cost that rises with adoption rather than a project that finishes, and handling the variance.

• Difficulty

Measuring what a unit of output actually costs in operation, and watching that number move.

• Difficulty

Changing the work rather than deploying a tool into work that stays the same.

• Difficulty

Carrying the organisation through a change that alters what people do, and what is owed to them while it happens.

• Difficulty

Producing evidence of benefit that a sceptical finance function accepts, rather than a number the programme produced about itself.

• Difficulty

What to do when the benefit did not arrive: continue, pause, stop or scale, and defending the call.

• Difficulty

Drift, degradation, and the supplier model change nobody told you about.

• Difficulty

Running the relationship as a live thing: performance, changes, renegotiation, and the review the contract entitles you to.

• Difficulty

How reversibility is lost quietly, and what has to stay in-house to keep a decision open.

• Difficulty

Deciding what the organisation must be able to do itself, and building for that rather than for everything.

• Difficulty

The standing account to the people entitled to ask: benefit, performance, risk position, and what went wrong.

• Difficulty

Reading operating reality back against the thesis, concluding it is wrong, and forcing the revision.

• Difficulty

Model, training, fine-tuning, prompt, token, context, inference, agent: the vocabulary of a technical meeting, defined well enough to follow one.

• Difficulty

How a model is fitted to data rather than programmed with rules, and what follows from that difference.

• Difficulty

What population a training set represents, and who is missing from it.

• Difficulty

The gap between the outcome an organisation cares about and the measurable thing standing in for it: readmission measured as a billing code, a good hire measured as three years of tenure.

• Difficulty

Trained, fine-tuned, prompted, grounded on your documents: which knob a supplier is turning, and what each one can and cannot fix.

• Difficulty

Predictive, generative, retrieval and acting systems, and what each is genuinely for.

• Difficulty

Problems that do not need a language model, and how to notice them before the project starts.

• Difficulty

Why the same question can produce different answers, and where that rules a use in or out.

• Difficulty

Fluency without a truth check, read as a mechanism rather than as a bug.

• Difficulty

Calibration: how a system's expressed confidence relates, and fails to relate, to whether it is right.

• Difficulty

Context limits, cut-off dates, and the document that was silently truncated.

• Difficulty

Data, objective, deployment context and user behaviour as the four sources, and how to tell which one you are looking at.

• Difficulty

What happens at the edge of the training distribution, and how to predict where a system will fail first.

• Difficulty

Bias as a mechanism rather than an accusation: how the composition of data shapes what a system produces.

• Difficulty

Where ground truth came from, who produced it, under what conditions, and how much to trust it.

• Difficulty

Why a system does not know your documents until it is made to, and what grounding does and does not fix.

• Difficulty

What changes once a model holds tools, credentials and the ability to take actions.

• Difficulty

Images, voice, documents and synthetic media: what these systems do well, where they fail, and where fabricated media becomes a live risk.

• Difficulty

Precision, recall, and what a rare event does to both.

• Difficulty

False positives against false negatives, chosen deliberately and in advance.

• Difficulty

How to read an evaluation claim, and what a benchmark result does not establish about your own use.

• Difficulty

What a demonstration is selected to show, and what turns it into evidence.

• Difficulty

Attack surface as a consequence of the mechanism: a system that takes instructions from text cannot fully separate instruction from content.

• Difficulty

Injection through content the system reads: an email, a document, a web page becoming an instruction.

• Difficulty

Memorisation and extraction: what a model can reveal about what it saw.

• Difficulty

Poisoning, and the provenance of a model or dataset somebody downloaded.

• Difficulty

Where the officer's own competence ends, and how to get an answer they can rely on.

• Difficulty

Drawing the edge of the thing being commissioned: user, task, data, decision, output, handoff.

• Difficulty

From source data through to a person acting on an output, and what sits between.

• Difficulty

Setting the standard a system must meet before anyone builds or sells one.

• Difficulty

Uses whose minimum standard comes from regulation, professional duty or the consequence of error, rather than from the organisation's preference.

• Difficulty

Assembling evaluation material out of the organisation's own reality, including the awkward cases.

• Difficulty

Data held back, and who marks the paper.

• Difficulty

Rubrics, expert review, and what to do when the experts disagree.

• Difficulty

Results broken down by subgroup, language, name, and edge population, rather than averaged.

• Difficulty

Specifying an adversarial test and reading the report it produces.

• Difficulty

A trial with a stated question, an end date and a stop available.

• Difficulty

Coverage, rights, freshness, lineage and operational availability of the data a system will depend on.

• Difficulty

Requiring proof of where data and models came from before taking delivery.

• Difficulty

Where a person sits in the process, and what authority they actually hold.

• Difficulty

Volume, seconds per case, and oversight that is arithmetically impossible.

• Difficulty

Automation bias, and how the interface causes it.

• Difficulty

Uncertainty, sources, and what the screen has to show for the output to be used properly.

• Difficulty

Fallback, containment, blast radius, appeal and rollback: what happens when it is wrong, decided before it is.

• Difficulty

Outage, rate limit and degraded mode, and what the organisation does that morning.

• Difficulty

Permissions, credentials and the boundary around a system that can act.

• Difficulty

Prompts, retrieval stores, logs and integrations as part of the security surface.

• Difficulty

Drift, quality, incidents and supplier change: what is monitored and what triggers a look.

• Difficulty

Logging, versioning and audit trail designed in, including how to do it without retaining what should not be kept.

• Difficulty

Prompt and configuration changes treated as releases.

• Difficulty

Disruption, training need and process ownership: the cost of integration into work as it is done today.

• Difficulty

Accessibility, language, and the person who cannot use the channel at all.

• Difficulty

Designing or joining a system that serves several institutions at once.

• Difficulty

Suspension, retirement, what happens to the data, and what takes over.

• Difficulty

Producing something a supplier can answer and the organisation can hold them to.

• Difficulty

Running acceptance against stated evidence rather than supplier confidence, and being willing to refuse.

• Difficulty

Comparing two proposals on what decides the outcome rather than on feature lists.

• Difficulty

Cloud, on-premise, sovereign, sectoral, shared: what each choice commits an organisation to.

• Difficulty

Residency, sovereignty, and access by a party the organisation never contracted with.

• Difficulty

Open weights, closed, hosted, licensed, and what each implies for control, cost and dependency.

• Difficulty

Reading a model licence and saying what use it actually permits.

• Difficulty

Prompts, uploads, logs and feedback: whether they train somebody else's system, and what the setting in the admin console actually changes.

• Difficulty

Subcontractors, model providers, data providers and infrastructure: what you depend on without having chosen it.

• Difficulty

People, hardware, upgrades and somebody on call: the honest price of the in-house option.

• Difficulty

Inference, storage, monitoring, support and review labour at ten times today's volume.

• Difficulty

Repricing, tier removal, and the free tier that ends.

• Difficulty

Versions, pinning, notice periods, regression testing and deprecation.

• Difficulty

Latency, capacity, availability and accessibility as thresholds set before signature.

• Difficulty

Identity, least privilege, tenant separation and logging: the integration the security function will demand later.

• Difficulty

Designing a comparison whose result means something.

• Difficulty

Viability, ownership and acquisition: what happens to you if they are bought or fold.

• Difficulty

Concentration, and the outage or policy change that reaches a whole sector at once.

• Difficulty

Data, workflow, prompts, indexes, formats and accumulated know-how: the things that make leaving hard.

• Difficulty

Specifying an exit that would actually work.

• Difficulty

Free tiers, personal accounts and AI switched on inside software already owned.

• Difficulty

Working inside rules that can remove the option you judged best.

• Difficulty

Frameworks, joint purchasing, and peer institutions pooling one system.

• Difficulty

Judging a platform that serves many institutions at once.

• Difficulty

Energy, water and what the organisation will be asked in public.

• Difficulty

A routine for staying current without living in the news.

• Difficulty

One defensible answer on what to acquire, from whom, on what terms and with what exit.

• Difficulty

Writing down the facts every legal question in this module is answered from: the system, its users, the people affected, who provides it, who deploys it, and where.

• Difficulty

The logic behind the rules: risk to people, accountability along a chain, and evidence that something was done.

• Difficulty

Definitions and scope, including the spreadsheet or rules engine nobody thought counted.

• Difficulty

Scope, definitions, obligations and annexes, and where the operative sentence actually hides.

• Difficulty

Prohibited practices, and recognising one early enough to stop it cheaply.

• Difficulty

Placing a system in a risk class and justifying the placement.

• Difficulty

Provider, deployer, importer, distributor, public authority, joint arrangement: the duties differ sharply between them.

• Difficulty

Fine-tuning, rebranding, substantial modification, or putting a system to a new purpose.

• Difficulty

Turning a classification and a role into a list of things that must exist.

• Difficulty

Placing a bought or embedded model inside your own obligations.

• Difficulty

Conformity work, registration and declarations, and who performs each.

• Difficulty

How a management standard turns a legal requirement into something a person can actually do.

• Difficulty

Safety regimes and professional duty: the second regulator nobody expected.

• Difficulty

Producing a rights assessment where one is required, and where it is merely wise.

• Difficulty

Duties that attach because of who is deciding: basis for the decision, reasons, and the right to be heard.

• Difficulty

Combining two regimes without dropping either.

• Difficulty

Turning an AI literacy obligation into a plan rather than a slide.

• Difficulty

Which regimes reach your deployment, your supplier and the people affected.

• Difficulty

Powers, inspection, penalties, and what the first letter looks like.

• Difficulty

Keeping a compliance calendar and planning against dates rather than being surprised by them.

• Difficulty

Codes, guidance, supervisory opinions, funder and insurer conditions.

• Difficulty

Noticing a legal change that hits something already live.

• Difficulty

Drawing the line around your own legal competence.

• Difficulty

Facts, options, and the decision waiting on the answer.

• Difficulty

Drawing the flow before arguing about any of it: what is personal, what is special category, what is inferred, and who receives it.

• Difficulty

Deciding whether the regime applies, including data that becomes personal once combined.

• Difficulty

Establishing a basis for this specific use, or concluding there is none.

• Difficulty

Purpose limitation meeting a system that wants everything: whether data collected for one thing may train or evaluate another.

• Difficulty

Testing whether a privacy claim survives a re-identification attempt.

• Difficulty

The system that learns a proxy for something the organisation never collected.

• Difficulty

Patients, applicants, employees, beneficiaries, anyone who cannot walk away.

• Difficulty

Reconciling a principle that says collect less with a technology that improves with more.

• Difficulty

Prompts, outputs and logs, and the retention rule that was never applied to them.

• Difficulty

Meeting access, correction, deletion and objection requests when the data is inside a model or its index.

• Difficulty

Deciding what transparency is owed, and to which audiences.

• Difficulty

Writing the notice in language somebody actually reads.

• Difficulty

When rights to explanation, human review and contest attach.

• Difficulty

Producing an explanation the person can act on and contest.

• Difficulty

Processors, subprocessors, transfers and remote access, including the transfer that happens through a supplier.

• Difficulty

Judging a use whose subject is the workforce.

• Difficulty

The data protection function and the roles the law names, and how the officer works with them.

• Difficulty

Producing an assessment that is useful rather than decorative.

• Difficulty

Groups, metrics and thresholds: what a fairness claim establishes.

• Difficulty

Definitions that conflict mathematically, and choosing one as a policy decision.

• Difficulty

Consultation designed so that it can still change the design.

• Difficulty

Building a route by which a decision can be challenged and overturned.

• Difficulty

The judgement that remains once every legal test is satisfied.

• Difficulty

The system refused that would have helped somebody.

• Difficulty

Data workers, source material and environmental cost: answering for how the thing you bought was made.

• Difficulty

Changing data, design, oversight, scope or purpose until an unacceptable use becomes defensible, or concluding that it cannot.

• Difficulty

Who may claim, against whom, and on what theory when an AI system causes harm.

• Difficulty

What attaches to the individual, and what protects them.

• Difficulty

The gaps in a supplier's own paper, found before signing.

• Difficulty

Whether the protection offered has practical value.

• Difficulty

Securing in the contract what governance will be asked for later.

• Difficulty

Controlling a chain you never signed with.

• Difficulty

Writing commitments that mean something where correctness cannot be promised.

• Difficulty

Governing law, forum, and whether a remedy could actually be enforced.

• Difficulty

Finding out what the cover excludes before the claim rather than after.

• Difficulty

Whether the organisation may use the data, documents, images, code and third-party content it intends to feed a system.

• Difficulty

The exposure inherited with somebody else's model.

• Difficulty

What the organisation owns, may publish, and can rely on.

• Difficulty

Tracing an open-weight or content licence through to what the live system may do.

• Difficulty

Resemblance, marks, and statements about real people.

• Difficulty

Confidentiality and trade secrets in the everyday use of outside services.

• Difficulty

Claims in tenders, funding applications, marketing and public statements.

• Difficulty

The claim that arrives from equality law rather than from data protection.

• Difficulty

Meeting workforce obligations properly rather than formally.

• Difficulty

Allocating responsibility across consortia, shared services and local deployers.

• Difficulty

Transparency, equal treatment and specification rules that start before the negotiation.

• Difficulty

Recording decisions, assumptions, tests, warnings and accepted risk so that a question in two years has an answer.

• Difficulty

Suspending deletion once a dispute becomes foreseeable.

• Difficulty

What will be requested, and who has to produce it.

• Difficulty

Termination, transition assistance and getting your data back.

• Difficulty

plan a sequential or concurrent mixed-methods design and justify the integration point.

• Difficulty