AI has a habit of sneaking into products sideways.
It starts as a support experiment. Then it becomes an internal admin helper. Then a customer-facing summarisation feature appears behind a flag. Someone adds model-assisted tagging. Another team connects a third-party API to speed up onboarding. Six months later, nobody is quite sure which features use AI, which model is behind each one, what data is being sent, or who is responsible when the output is wrong.
That is not a governance strategy. It is a treasure hunt with invoices.
For UK software teams, the useful next step is not necessarily a huge AI compliance programme. In many small and mid-sized product companies, the best first move is more boring and more valuable: keep an AI feature register.
A feature register is a maintained list of the places where AI is used in or around the product. It records what the feature does, who owns it, what data it touches, what risk category it appears to sit in, what users are told, which supplier or model is involved, and how the team monitors it after release.
That sounds administrative. Done well, it is product infrastructure.
Why this matters now
The regulatory and operational mood around AI has changed.
The EU AI Act is now moving through its phased application timeline. The European Commission says prohibited AI practices and AI literacy obligations started applying from February 2025, general-purpose AI model obligations became applicable from August 2025, and many transparency and high-risk rules come into effect from August 2026, with some high-risk systems embedded in regulated products following in August 2027.
UK companies are not automatically outside the conversation just because the UK is no longer in the EU. If a UK product serves EU users, sells into the EU market, or produces AI outputs that reach EU customers, the Act may become relevant. The exact legal answer depends on the product, the role the company plays, and the use case. That part needs proper legal advice.
The product direction is clearer: teams need to understand their AI usage before they can sensibly classify, explain, secure or improve it.
The UK side points the same way. The ICO’s AI and data protection guidance includes detailed support on applying UK GDPR principles to AI systems, explaining AI-assisted decisions, and assessing risks to people’s rights and freedoms. The NCSC’s secure AI system development guidance also pushes teams to treat security as a lifecycle concern across design, development, deployment, operation and maintenance.
Different documents, same practical message: know what you have built.
The problem with invisible AI
Invisible AI usage creates awkward gaps.
A salesperson might promise that customer data is never used for model training, while a prototype feature is still sending prompts to a third-party service with unclear retention settings. A support team might rely on an AI-generated account summary without knowing whether it can hallucinate customer history. A product manager might describe a feature as a harmless assistant, while the customer experiences it as an automated decision.
None of those problems require bad intent. They happen when AI features move faster than the organisation’s shared understanding.
The risk is not only legal. It is operational.
If a customer asks where AI is used, can the team answer without opening six Slack threads? If a supplier changes its model, can anyone tell which features are affected? If a user challenges an AI-assisted output, does support know the escalation route? If security reviews the product, is there a current list of model calls, data flows and monitoring controls?
Without a register, the answer is often: “we think so”.
That is not a phrase anyone wants to hear during procurement, incident response or a board meeting.
What an AI feature register should include
This does not need to be heavyweight.
A useful first version can live in a structured document, spreadsheet, Notion database, issue tracker or internal admin page. The format matters less than the habit of keeping it current and using it in product decisions.
For each AI-enabled feature, record the basics:
- the feature name and where it appears in the product
- whether it is customer-facing, internal-only or used by support/admin teams
- the feature owner and engineering owner
- the supplier, model or API involved
- the data sent into the system, including any personal data or sensitive business data
- what the AI output affects: advice, content generation, triage, scoring, automation or decisions
- whether users are told AI is involved
- whether a human reviews or can override the output
- the main failure modes and known limitations
- logging, monitoring and incident handling arrangements
- links to the DPIA, risk assessment, security review or supplier notes where relevant
That list looks longer than it feels in practice. If a team cannot fill it in for a feature, that is the register doing its job. It has found an assumption.
The register should also capture status. Is the feature experimental, in beta, generally available, retired, or used only in a controlled internal process? AI prototypes are especially worth tracking because they have a nasty habit of becoming production dependencies through sheer convenience.
Classification starts with inventory
A lot of AI governance conversations jump straight to classification.
Is this high-risk under the AI Act? Is it a transparency-risk system? Is it merely a low-risk productivity feature? Is the company a provider, deployer, importer, distributor or something else? Those questions matter, but they are hard to answer if the product team has not first described what the feature actually does.
The European Commission’s AI Act materials describe a risk-based regime: prohibited practices, high-risk use cases, transparency obligations and minimal-risk AI. They also highlight strict obligations for high-risk systems, including risk management, dataset quality, logging, documentation, clear information to deployers, human oversight, robustness, cybersecurity and accuracy.
Most ordinary product features will not be high-risk. That is not an excuse to skip the inventory. It is a reason to keep the process proportionate.
A register lets a team separate the genuinely sensitive features from the routine ones. A customer support draft assistant is not the same as an employment screening tool.Treating everything as equally dangerous creates noise. Treating everything as harmless creates risk.
The useful middle ground is visible, documented judgement.
Transparency is a product experience, not a footer
One of the more practical AI Act themes is transparency. The Commission says users should be informed when they are interacting with systems such as chatbots, and that certain AI-generated content should be identifiable or labelled.
Even outside formal EU obligations, this is simply good product design.
If AI is involved in a customer-facing feature, users should not have to guess. They should understand what the feature can do, what it cannot do, and when a human can review the result. The wording should be close to the feature, not buried in a policy nobody reads until something goes wrong.
A register helps because it gives product and design teams a map of where transparency decisions are needed.
For each feature, ask:
- does the user know AI is involved?
- is the explanation written in plain English?
- does the product make the limits obvious at the right moment?
- can the user correct, reject or escalate an output?
- are support staff equipped to explain what happened?
Transparency is not solved by adding “powered by AI” to a screen. That can be branding, not clarity. Real transparency helps the user make a better decision.
Security needs the same register
AI features have normal software risks and some AI-specific ones.
The NCSC guidance is useful because it frames secure AI development across the full lifecycle: secure design, secure development, secure deployment, and secure operation and maintenance. It calls out risk understanding, threat modelling, supply chain security, documentation, incident processes, logging, monitoring and update management.
Those are not abstract concerns. A product team using an external model API needs to know what prompts contain, where logs are stored, how secrets are managed, how rate limits and failures behave, and what happens if the model returns unsafe or nonsense output. A retrieval-augmented feature needs to know which documents can be pulled into context and how permissions are enforced. An AI admin assistant needs guardrails so it does not turn a helpful shortcut into an accidental privilege escalation.
A feature register gives security something to review.
It also prevents supplier drift. If a team swaps models, adds a fallback provider, changes prompt logging, or introduces a new vector database, the register should change with it. That is where lightweight governance earns its keep: not in a quarterly slide deck, but in catching the quiet changes that alter the risk profile.
Data protection is easier when the product map exists
The ICO’s AI resources focus heavily on applying data protection principles to AI and assessing risks to individuals’ rights and freedoms. That is difficult if nobody can say what personal data is used, why it is needed, how long it is retained, or whether outputs could affect people in a meaningful way.
A register does not replace a DPIA. It makes DPIAs and privacy reviews less painful.
It gives the team a shared starting point:
- what data is collected or submitted
- whether prompts include personal data
- whether the model provider stores inputs or outputs
- whether training, fine-tuning or evaluation data is involved
- whether automated outputs affect customers, staff or end users
- what review or appeal route exists
For many B2B products, the sensitive issue is not dramatic science fiction. It is mundane data leakage. A user pastes customer details into a summariser. A support agent sends account context to a model. A logging system stores prompts in a place the customer did not expect.
The register makes those flows visible before they become uncomfortable.
How to introduce one without creating bureaucracy
Start small.
Pick the current product, list every known AI-assisted feature, and include internal tools if they touch customer data or influence customer outcomes. Do not spend the first session arguing about perfect taxonomy. Get the obvious facts down.
Then add three routines.
First, make the register part of feature definition. If a new feature uses AI, the product brief should include the register fields. That forces early decisions about data, ownership, transparency, review and monitoring.
Second, make it part of release review. Before launch, check that the register is complete enough for the feature’s risk level. A low-risk internal drafting tool may need a short entry. A customer-facing recommendation or decision-support feature needs more.
Third, review it when suppliers, models or data flows change. AI products are unusually fluid. If the implementation changes but the register stays still, it becomes decorative. Decorative governance is just compliance bunting.
The owner should usually be product, not legal. Legal, security and data protection teams should contribute, but product is closest to the user experience and roadmap trade-offs. If product does not own the register, it becomes something people update after the important decisions have already been made.
What good looks like
A healthy AI feature register is not impressive because it is long.
It is impressive because it is used.
It helps a product manager decide whether a new feature needs human review. It helps engineering spot a risky data flow. It helps support answer a customer question accurately. It helps sales respond to procurement without inventing policy on the spot. It helps leadership see where AI is creating value and where it is creating fragility.
It also supports better product judgement.
Some AI features should ship quickly because they are low-risk, helpful and reversible. Some should move slowly because the failure modes affect people’s rights, money, work, access or trust. Some should not ship at all until the team can explain them properly.
That is the point. The register does not exist to stop AI work. It exists to make AI work legible enough that the team can move with confidence.
The bigger lesson
AI governance sounds like a legal or policy topic, but in product companies it quickly becomes a craft topic.
Can the team describe what the feature does? Can it explain the limits? Can it secure the data flow? Can it monitor outputs? Can it respond when something goes wrong? Can it tell customers the truth without scrambling?
Those are product questions.
For BPS Designs, this is the practical angle: AI features should be treated like real product capabilities, not magic dust sprinkled across the roadmap. Real capabilities have owners, documentation, risk controls, release criteria and support paths.
A lightweight AI feature register is not glamorous. That is fine. Neither are backups, audit logs or dependency inventories.
They are still the things mature teams are grateful for when the interesting part of the product suddenly becomes the risky part.