AI model governance

Introduction

AI models used by the product need their own governance model. They sit close to customer workflows, user data, automatic processing and contractual promises, so they need stronger control than delivery agents used internally.

Knowledge scope

This is common CTO knowledge. It applies beyond the startup journey, but the public playbook places it where it usually becomes important for an early-stage company.

Why it matters

Customers may enter names, emails, case notes, commercial details, staff information or other personal data into product features. The model boundary becomes part of the product data boundary, not an experimental side channel.

How it fits the playbook

This reference supports the POC Started -> Pilot Ready stage of the startup CTO playbook. It gives the public context for the decision without exposing the deeper assessment method behind the agentic operating model.

Design considerations

• Know which product features use AI and what data is sent to each model.
• Understand inference location, data residency, retention and provider training terms.
• Keep UK or EU promises aligned with prompts, embeddings, files, responses and logs.
• Use redaction or routing controls where models should not receive raw personal data.
• Treat prompt history as evidence for validation and regulated processing where appropriate.

What good looks like

The product can explain where AI is used, what data is processed, where processing happens and how model outputs are reviewed, retained and validated.