Step 1: define the use case and its data boundary
Before any code, write down what the tool does, who uses it, and which data classes it may handle. Name the data that must never leave your boundary in clear text, the providers you trust, and the outcomes the tool must produce. This boundary is the specification the rest of the build enforces. Tools that skip this step inherit a boundary by accident, usually whatever the model provider defaults to, and that is how personal data ends up in an external system no one chose.
Step 2: route every request through one control point
Do not let your tool call a model provider directly from scattered code paths. Send every AI request through a single layer that sits in front of the providers. One control point is what makes governance possible: it is the only place you can reliably intercept a request, apply policy, and record what happened. Direct calls spread across a codebase cannot be governed consistently, because each path has to re-implement the same controls and one of them always drifts.
Step 3: redact sensitive data in transit
At the control point, strip or mask the data classes you named in step one before the request reaches an external model. Redaction in transit means the provider never receives identifiers it does not need, which shrinks both your privacy exposure and your audit burden. Build this as a default-on rule, not an option a developer remembers to enable, so a new feature cannot accidentally ship without it.
Step 4: enforce policy and route to approved models
Have the control point check each request against the policy for that user and use case: is this caller allowed, is this model approved for this data, is this action within scope. Allow, block, or modify the request before it executes. For tools that use agents, apply the same check to each tool call the agent makes, with a scoped identity per agent. Enforcement before execution is the difference between a tool that respects its boundary and one that merely logs crossing it.
Step 5: record evidence as the tool runs
Write an audit record for every request as it passes the control point: which policy applied, what was redacted, which model handled it, and the outcome. When evidence is a by-product of enforcement, you can answer what the tool did and why, mapped to obligations like the EU AI Act and ISO 42001, without a separate reporting project. Wire this in from the first release. Retrofitting an audit trail onto a tool already in production is far harder than building it in from step two.
Frequently asked questions
Do I need a control point for a small internal AI tool?
Yes, even a small tool sends data to a provider and makes decisions worth recording. A single control point keeps governance consistent and is far cheaper to add at the start than to retrofit later.
What is the most common mistake when building AI tools?
Calling model providers directly from many code paths, which makes consistent redaction, enforcement, and audit nearly impossible. Routing every request through one layer fixes it.