--- title: AI diligence description: Handling data responsibly, disclosing AI involvement, and owning AI-assisted output — consult when a workflow touches personal or confidential data, when output leaves the team, or when someone asks who is accountable for what an AI produced. category: principles updated: 2026-09-09 --- # AI diligence **AI diligence** is responsibility for AI-assisted work: choosing tools appropriately for the data involved, telling people what the AI did when they have a reason to know, and standing behind the result. It is the competency most often missing from practical AI training, because unlike a better prompt or a faster workflow it produces nothing visible. A workflow can pass every quality check and still fail here, since the failure is not in the output but in a question nobody asked. The competency splits three ways, following the AI fluency framework. Creation diligence covers responsible use during the work: what data goes where, and under whose terms. Transparency diligence covers telling the audience, calibrated to their expectations and the norms of the field. Deployment diligence covers verification and ownership: a named person checks the work and carries the consequence if it is wrong. See: ai-fluency-framework. A caution that governs everything below. Regulation, vendor terms and product behaviour all change faster than reference material does. The durable content here is which questions to ask and where the answers live. Specific obligations and retention periods must be checked against the primary source at the time of use, and none of this is legal advice. ## Creation diligence: knowing where the data goes The instinct that an organisation is protected because staff are signed in with work accounts is wrong, and the way it is wrong is instructive. Protections attach to the licence tier and the administrative configuration, not to the account. Major vendors publish contractual commitments not to train on customer content for their business tiers, while the consumer tiers of the same products may do the opposite, including human review of a sample of conversations and multi-year retention of reviewed material. A user on an unqualified licence can be typing into an interface that looks identical to a colleague's and be under an entirely different regime. This makes the first diligence question an administrative one rather than a philosophical one. Which tier are we actually on, what has the administrator enabled, and does that cover everyone who will touch this workflow? The second question is where the commitment is written. Vendor marketing pages and help articles often qualify a claim in ways the contract does not, or bind two separate assurances into one sentence so that a qualifier attached to one appears to cover both. The binding statement lives in the commercial terms and the data processing agreement. When a claim matters enough to design around, cite the contract. Data protection law adds a framing that is easy to miss. Training a model and operating it are treated as separate purposes, each needing its own legal basis, and a system that keeps learning during use introduces a third. The practical consequence for an ordinary organisation is that buying a tool does not inherit the vendor's basis for having built it. Reusing data already held for a new AI purpose is a new purpose, which can trigger a fresh duty to inform the people concerned even though the data never left the building. Danish supervisory guidance works exactly this case through examples where an organisation reused its own records for an AI project without telling anyone, and the failure was the notice, not the technology. Where an assessment is required for high-risk processing, it belongs in the planning phase. Retrofitting data protection onto a finished system is expensive and sometimes impossible, which is the same argument as designing verification in before a workflow runs rather than after it disappoints. None of this prevents testing. When the real data is confidential, the answer is to test on invented data with the same shape: same fields, same messiness, same edge cases, no real people. A workflow tested only on clean examples is untested, and a workflow tested on live personal data in an unapproved tool has already caused the problem it was meant to avoid. ## Transparency diligence: telling people what the AI did Three separate floors govern disclosure, and conflating them produces both false alarm and false comfort. The legal floor is narrow. Under the EU AI Act, the obligations on marking synthetic content and on designing systems that announce themselves fall on providers, meaning those who build systems or place them on the market, not on organisations that buy and use them. The clause that reaches an ordinary user applies to deployers who publish AI-generated or manipulated text with the purpose of informing the public on matters of public interest. Internal drafting is outside it, because internal drafting is not published. The obligation is disapplied where the content has undergone genuine human review or editorial control and a person or organisation holds editorial responsibility for the publication, and the Commission has indicated the review must be a deliberate examination of substance rather than a formal or procedural check. These transparency provisions have been in application since August 2026, unlike the high-risk provisions, which were postponed. Two of the terms that decide scope are undefined in the regulation itself. Neither "published" nor "matters of public interest" carries a definition, and Commission guidance describes the latter broadly enough to reach economic and cultural developments that may be a subject of public debate. Anyone stating confidently that a company newsletter or a marketing blog is inside or outside is going beyond what the text supports. The honest position is that the case is unclear, and that an organisation publishing at any scale should form a policy rather than wait for the ambiguity to resolve. The professional floor is often stricter and more specific than the law, and it is where most real answers live. Danish press ethics are a useful worked example because they are explicit. The press guidelines in force since 2024 bring editorial content produced wholly or partly with AI inside their scope, which means complaints about it can be heard. On labelling they deliberately decline to impose a general duty, leaving each publication to decide whether and how to declare AI use, with one mandatory exception: where AI is used to depict events that never happened, through synthetic imagery, voice duplication or manipulation, declaration is required. They also require publications to maintain structures that keep control over how their algorithms behave, and they hold AI-assisted content to the same accuracy standard as anything else, noting that manipulable images and audio no longer constitute documentation on their own. The pattern generalises beyond journalism. A sector's own rules usually answer the disclosure question more precisely than the legislation does, they frequently arrive earlier, and they often place the duty on process and verification rather than on labelling. The third floor is expectation, and it covers most work. Nothing legal or professional compels a person to say an AI drafted an internal memo. What governs is whether the recipient would feel misled to learn it, which depends on the relationship rather than the content. The workable test is to ask who receives this, and whether they would be surprised. A colleague expecting a considered personal judgement and receiving a generated one has been misled even where no rule was broken. A reader of a routine summary generally has not. ## Deployment diligence: verifying and vouching The most useful statement of this competency is not in any framework but in vendor contracts. Commercial terms typically assign output ownership to the customer and, in the same breath, place the evaluation duty there too: it is the customer's responsibility to decide whether output suits the intended use, including whether human review is appropriate, before using or sharing it. The vendor has already declined to vouch for the work. Someone has to, and the contract says who. This is why naming an owner is a real design step and not administrative tidiness. Every workflow that produces output leaving the team needs a person, not a role and certainly not the system, who verifies before it goes and answers for it afterwards. The requirement bites hardest at rollout, when a workflow spreads to colleagues who did not build it and who inherit its failure modes without having seen them fail. Rollout should carry the known limits, not just the instructions. Ownership also decides what happens when something goes wrong, and something will. A workflow that has run for months without a single incident recorded is usually not clean, it is unmonitored. Logging what reached someone else before it was caught costs seconds and is the only way a compounding mechanism ever learns about the failures that matter most. See: compound-engineering. ## Making it operational Diligence resists checklists because the questions are few and the judgement is everything. Four questions, asked at the points where they are answerable, cover most of it. When a workflow is first mapped, before anything is designed: which steps touch personal or confidential data, and is the tool approved for it? A step that fails this is not a candidate no matter how well it scores on every other measure. When the workflow is designed: who receives the output, and would they need to know an AI was involved? Answer against the organisation's norm where one exists, and record the absence where it does not, because an unrecorded gap is how a default becomes a decision nobody made. When it moves into daily use: if this output leaves the team, how is AI involvement disclosed, and who owns the workflow? Both answers belong in whatever document the workflow lives in. When it runs: did anything go out wrong before it was caught? The value of the answer is not the incident but the pattern across incidents. Answering these takes minutes, which matters, because a diligence practice that costs more than that will be skipped in a busy week exactly as any other overbuilt mechanism is. See: ai-workflow-redesign. ## Related pages - See: ai-fluency-framework - The competency model this page expands, and the other three competencies - See: ai-output-verification - How to judge output well enough to vouch for it - See: ai-workflow-redesign - Where these questions attach to the phases of redesigning a workflow - See: compound-engineering - Turning captured incidents into a workflow that improves - See: personal-agents - Why rollout gives each colleague their own copy, and what that means for ownership