Drag a page edge to turn. Or use the arrows.
Organisations of every size.
In the age of AI.
Jonas Hertner
Working outline
Fourteen chapters.
One connected operating plan.
Build the ability to make and carry out sound legal decisions. Then keep that ability effective as circumstances change.
A legal function connects an organisation’s purpose to its rights, obligations and decisions. Its responsibilities may sit with managers, an internal team, external advisers and systems. The first question is what must happen—and who can make it happen.
The same questions apply across four starting points: no employed lawyer, first counsel, a growing team and a distributed function. Legal complexity, resources and consequences determine the arrangement. Size alone does not.
An essential function of law is to facilitate social collaboration. The book therefore treats human understanding as a guiding principle when optimising legal work for machines. The aim is to use large language models to make law more accessible to people, with time to think, discuss and reflect.
Every chapter produces a decision and something usable.
Start with the organisation’s purpose and the choices it must make. Identify duties that cannot be traded away, the rights worth protecting, and the activities the function should enable.
Build: A purpose and mandate charter that defines the function’s responsibilities and limits.
Change one fact: The organisation takes on a public mandate. Which purposes and constraints need to change?
Map recurring work, unfamiliar decisions, jurisdictions, sensitive assets and consequences of failure. Find the work nobody recognises as legal, and the work that never reaches the legal team.
Build: A demand and capability map, including important assets and the assumptions protecting them.
Change one fact: A small organisation enters a heavily regulated market. What capacity becomes necessary?
Separate advice from authority and execution. Give reviewers the competence, information, time and standing to challenge a decision, including one favoured by senior management.
Protect time to think and reflect before consequential decisions. Deliberation is part of the work.
Build: A decision and escalation map with named responsibilities.
Change one fact: The person requesting advice is also the subject of an allegation. Who takes responsibility?
Compare internal counsel, external specialists, fractional leadership, managed services, self-service and software. Include coordination, verification, continuity and failure costs in the comparison.
Build: A sourcing decision with alternatives and their total resource requirements.
Change one fact: Your main adviser becomes unavailable. Can the function continue?
Establish issue recognition, accountable owners, reliable deadlines, organised records and access to competent advice. Define referral triggers and the point at which additional capacity is justified.
Build: A minimum capability checklist and hiring triggers.
Change one fact: There is no budget for a full-time lawyer. Which responsibilities still need an owner?
Design roles around the work and the relationships that make it possible. Develop judgment, preserve access to expertise, and plan for succession as AI changes how experience is acquired.
If rules optimised for information exchange between machines become harder for laypeople to understand, the lawyer’s role as an interpreter may become more important. Explain meaning, choices and consequences so that people can discuss them and take responsibility.
Build: A roles, development and succession plan.
Change one fact: Routine work is automated. How will less experienced colleagues learn to recognise difficult cases?
Follow the whole matter: facts, options, recommendation, approval, action and follow-through. Locate handovers, missing information and unowned obligations before automating individual steps.
Machine-to-machine contracts may be efficient to negotiate, transmit and execute, yet ineffective in supporting social collaboration. Ask whether the people concerned can understand their commitments, coordinate their actions and resolve disagreement. Judge the arrangement against that purpose.
Build: A service catalogue and responsibilities for follow-through.
Change one fact: A contract is signed, but its reporting obligation has no owner. Where should the process have caught this?
Connect advice and approvals to their facts, sources, conditions and owners. Decide what deserves continuing attention, what should be reviewed after an event, and what should be retired.
Build: A selective knowledge plan with review triggers and upkeep costs.
Change one fact: An approved supplier changes where it processes data. Who notices, and which part of the approval needs reconsideration?
Choose uses based on their contribution to the work. Compare AI with simpler improvements. Account for confidentiality, permissions, task difficulty, checking effort and the consequences of an error.
Use LLMs to help people understand, question and use the law. When optimising for machines, make greater human accessibility an explicit objective and preserve time for people to consider the consequences. Design for people to recognise a problem, understand their rights and obligations, and take an appropriate next step. Include prevention and avoiding escalation among the intended outcomes.
Build: A shortlist of uses with an economic case and clear boundaries.
Change one fact: Drafting becomes almost free, while review takes just as long. Where is the actual bottleneck?
Test people, models, information and workflow together on representative work. Compare people working alone, people using AI, people reviewing AI work, and systems acting within defined limits where appropriate. Use independent evidence under the conditions in which each arrangement will operate. Examine omissions, factual and legal support, permissions, organisational fit and successful execution. Record the configuration and the limits of the evidence.
Evaluate whether people can understand the result, recognise uncertainty and discuss its implications. Test whether the system supports collaboration as well as whether it transmits information and executes tasks efficiently. Separate evidence about capability from decisions about who should hold authority.
Build: A comparative evaluation and total-effort assessment.
Change one fact: The provider replaces the model. Which earlier results still support its use?
Connect governance to actual decisions and controls. Define access, permitted actions, supervision and intervention. Allocate responsibilities across legal, security, procurement and business owners, with jurisdiction-specific duties made explicit.
Build: An AI responsibilities and control plan, including supplier change and exit arrangements.
Change one fact: A protection relied on by a vendor receives a credible adverse security finding. Who assesses its scope and authorises the response?
Make resourcing choices visible. Measure coverage, decision quality, delay and follow-through alongside spend. Include the work of checking, maintaining, correcting and developing capability. Distinguish avoidable delay from time needed for thought and reflection.
Build: A budget and a balanced set of performance measures.
Change one fact: The team closes more matters, but unrecognised obligations accumulate. What are its metrics missing?
Prepare for conditions in which interests conflict and normal arrangements strain. Preserve evidence, independence and a clear route to action. Learn from failures without obscuring responsibility.
Build: Escalation, response and learning procedures.
Change one fact: A security incident affects records that must remain confidential and provable for years. What must be preserved, assessed and communicated?
Bring the chapter outputs into one operating plan. Sequence the work, assign owners, fund upkeep and set review points. Make it possible to change suppliers, replace technology and stop practices that no longer justify their cost.
Separate immediate improvements from preparation for different future capabilities. Set review triggers and alternatives without treating forecast dates as established facts.
Build: An implementation, maintenance and handover plan.
Change one fact: The organisation’s strategy changes. Which parts of the legal function should change with it?
The book starts from a demanding planning assumption: exposed products, processes and systems may become easier to inspect, imitate or reconstruct. Cryptographic and other security assumptions may weaken during the life of a decision.
For each important asset, record what protects it, how long that protection must hold, what would reveal a problem, and how long a change would take. Technical feasibility, legal permission and commercial value each need their own assessment.
Distinguish evidence from scenarios. Reproducing useful behaviour does not necessarily recover the original design or a secret key. AI-assisted cryptanalysis and quantum attacks are separate developments. A finding about one algorithm or implementation does not establish that all cryptography has failed.
The recurring question: What does this decision depend on—and who acts when that changes?
An approval is a decision made on stated conditions. This fictional example shows how the organisation keeps track of what it relies on.
Approve a supplier for a defined support workflow.
The supplier reports a processing location absent from the approved schedule.
Review lead: First counsel, coordinating with the business owner and relevant specialists.
The signal prompts an assessment. A named decision-maker records any revision and its reasons.
Fictional teaching example. Actual duties and responses depend on the facts, agreement and applicable law.
The intended publication combines a complete print book and accessible EPUB with a maintained digital edition. Enduring institutional choices belong in the main argument. Current technical evidence, jurisdiction notes and tools need dated reviews and a clear history.
Research monitoring is underway. Findings enter an editorial review queue; they do not automatically become advice. The proposed rhythm is reviewed digital releases when warranted, normally monthly, with quarterly audits and urgent corrections when needed.
A future reader should be able to ask: What has changed since I read this? The answer should show which assumption changed, the supporting evidence and the practical consequence for their organisation.
This page is a working outline, not the finished book or an operational update service. Chapter structure and publication arrangements remain in development.