Chapter 6 of 7 · ~3 min
Answering for it
The question came at the year's end, and from within the company. The finance director, reviewing the discount figures, observed that discounts above the fifteen per cent policy had risen since the desk was automated, and asked the question finance directors ask every year: who had approved them, and on what basis? In most companies that question is answered from email threads and memory, over the course of a week, and not well. Nadia answered it in an afternoon, from the record, which listed every above-policy discount, the representative who had approved it, what he or she had been shown at the time, and what the rule had proposed. The rise proved to be real and deliberate: Tom had been approving twenty per cent for hotel groups placing repeat orders, and the record showed each case.
Policy as structure
Herein lies the difference between a policy document and a structure. The rule that an agent may draft quotations but may not issue them above policy was not a sentence in a document; it was an approval step, and every run that had passed through it was on record. The rule that no step may spend beyond a given amount was a limit on the step. The rule that only the sales team may approve discounts above fifteen per cent was a role bound to a team. Because the policy resided in the process, it was reviewed with the process, versioned with it, and visible in every run that had complied with it. A policy that does not reside in the process is, in the end, an aspiration.
Who may change what
Around the workflows sit the rules of the workspace, which determine who may build, who may deploy and who may operate; which projects a team may see and reuse; and a shared library in which one team's well-made workflow becomes another's starting point, so that standards spread by example rather than by instruction. Every administrative change is entered in the same unalterable log as the runs. When the finance director's next question was who could change the process and when it had last been changed, the answer was a list. When, some months later, a large customer's due-diligence questionnaire arrived with a page of questions about the use of AI in the sales process, as such questionnaires increasingly do, the same record answered it.
The frameworks
Boards and regulators increasingly put these questions in the language of published frameworks: Singapore's Model AI Governance Framework and its edition for generative AI, the NIST AI Risk Management Framework, ISO/IEC 42001, and the EU AI Act's obligations in respect of high-risk uses. Their principles overlap to a considerable degree, covering accountability, human oversight, transparency, security, data governance, testing and record-keeping, and each corresponds to something this course has already shown. The table below sets out the correspondence, with one caution that should be stated without qualification: Chatterfly does not make an organisation compliant. It provides the mechanisms. The organisation's own policies, evidence and reviews do the rest, and the final column of the table records what remains its responsibility.
Experiment
Runs in your browserOne row for each principle, showing what the platform provides, the chapter of this course in which it was shown, and what remains the organisation's responsibility.
| Principle | What the platform provides | Shown in this course | Your responsibility |
|---|---|---|---|
| Accountability and internal governance | Workspace roles for who may build, deploy and operate; projects and teams that attribute every run, permission and cost; an append-only audit log of administrative changes and runs. | This chapter | Naming the accountable owners, and the review cadence. |
| Human oversight and control | Approval and input steps with a named role; timeouts that escalate; the ability to hand a run to a person or take over a conversation. | Chapter 4 | Deciding which decisions need a person, and who. |
| Transparency and explainability | The workflow definition as the readable record of where models act; runs replayable step by step with inputs, outputs and the rule or model that produced each. | Chapter 3 | What you disclose to customers and employees, and how. |
| Security and resilience | Private deployments by default; tools granted per step; run-scoped credentials; encrypted connections the model never sees; fallback models. | Chapter 4 | Your threat model, access reviews, and incident response. |
| Data governance | Knowledge bases bound per step with document-class boundaries; state visible in every run; retention settings per workspace. | This chapter | Data classification, lawful basis, and retention periods. |
| Robustness, testing and assurance | Validation before any run; output schemas and validation with retries; test runs with a synthetic participant; full run records to compare. Evaluation suites in development. | Chapter 5 | Acceptance criteria per use case and who signs them off. |
| Record-keeping and incident reporting | Append-only run timelines and audit logs; an immutable usage ledger; deployments as immutable snapshots so any past run can be tied to the exact definition that ran. | Chapter 3 | Incident thresholds, reporting duties, and to whom. |
| Monitoring and continuous improvement | Adoption and outcome analytics over runs; per-step cost reporting; versioned definitions so changes are reviewable. | Chapter 5 | The metrics that matter to you and the review that acts on them. |
The table describes what the platform provides to help you meet each principle. Whether your organisation complies with any framework depends on your own policies, evidence and reviews, and on the edition of the framework that applies to you.
Big question
Which of your organisation's policies on AI could be written as a step in a process, and which could not?