Behavioural Governance For AI Products
Behavioural governance for AI products is the capability of making AI-influenced behaviour explicit, reviewable, and auditable in the interface layer. The documented evidence covers fraud policy configuration, systematic review screening, and biomedical AI data-boundary communication.
Behavioural governance is applied to the interface layer, not to model training or model evaluation.
Behavioural requirements specify what an AI system should and should not do; governance reviewers evaluate against these requirements.
Model/policy separation distinguishes model outputs, such as risk scores, from policy decisions, such as allow, block, or escalate.
In the documented Callsign case, bank risk teams under SCA and PCI DSS needed audit evidence for significant fraud control decisions.
In the Callsign case, each policy became a central governance object bundling conditions, triggered actions, performance data, relationships, and complete change history.
In the Puraite case, blinded mode withheld AI screening decisions from human reviewers during initial screening by default to reduce anchoring risk.
In the Owkin K case, dataset transparency and data provenance were treated as governance communication requirements because K operated on specified datasets rather than the general internet.
Callsign outcomes are client-reported, including contracts with Lloyds Bank and HSBC and design-system use for at least 2 years post-engagement.
The Callsign time-to-market reduction is approximately 6 months and is described as client/engagement-inferred, not as a measured comparison.
Summary
Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.
Behavioural governance for AI products is the design capability of making AI-influenced system behaviour explicit, reviewable, and auditable at the interface layer. In Creative Navy's documentation, behavioural governance does not refer to model training or model evaluation. It refers to the designed layer through which users, operations teams, risk teams, auditors, ethics committees, or other governance consumers can understand what the AI system does and what the product decides to do with AI outputs.
A behavioural governance capability is needed when an AI product influences decisions that must later be explained, reviewed, or evidenced. The documented cases include AI-driven fraud detection for enterprise banking, systematic review screening, and biomedical AI operating on defined datasets.
Behavioural governance applies to the AI interface layer rather than the model layer
Behavioural governance defines what an AI system does and does not do in terms that governance consumers can evaluate. Behavioural requirements are more precise than user stories and less technical than model specifications. They specify what the system should and should not do, and they are the reference point for governance review.
The design boundary is important. Behavioural governance is applied to the interface layer, not to model training or model evaluation. The capability concerns how AI behaviour is represented, constrained, explained, configured, overridden, and audited in product use.
Explainability is treated as a design problem in this context. The goal is to make AI decisions traceable in terms that a governance consumer can evaluate, even when the underlying model is not interpretable.
Governance consumers differ from end users
A governance consumer is the stakeholder who evaluates AI behaviour for compliance, procurement, or oversight. The documented vocabulary names risk teams, regulatory auditors, notified bodies, institutional review boards, and ethics committees as governance consumers. These stakeholders are distinct from end users.
Behavioural governance therefore requires interface structures that support oversight work, not only task completion by the direct user. A bank risk team evaluating fraud controls, a systematic review methodologist evaluating human independence, and a clinical research institution evaluating data-use boundaries each needs different governance evidence.
Accountability separation is part of this design problem. The interface must make clear which layer is responsible for which action: model outputs belong to the AI system, policy decisions belong to the operations team, and human actions belong to the user.
Model and policy separation makes AI-driven fraud control governable
In the documented Callsign fraud authentication case, the governance problem was AI-driven fraud scoring for enterprise banking. The model produced behavioural risk scores based on signals such as device fingerprint, location change, spend velocity, and prior failures. Automated policies acted on those scores through actions such as allow, block, and step-up authentication.
At the start of the engagement, fraud rules were scattered across database views and configuration tables. There was no policy-level object, no audit trail of policy changes, and no separation between current policy and historical policy. In enterprise banking demos, the interface generated governance questions instead of closing them.
Model/policy separation was the foundational architectural decision. The fraud scoring model and the policy layer were made architecturally distinct. Analysts governed the policy layer, while the model layer remained below it. This separation made it possible to design governance infrastructure around policy decisions rather than around opaque model behaviour.
Policy objects make fraud strategy auditable and configurable
In the Callsign case, policy became the central governance object. Each policy bundled the conditions it evaluated, the actions it triggered, the performance data showing historical effectiveness, the relationships to other policies, and the complete change history.
This structure allowed a governance reviewer to navigate a policy and get a complete audit picture without escalating to engineering. The policy engine acted as a designed layer between AI model outputs and real-world decisions. It made AI-driven fraud detection auditable and configurable at the level risk teams needed to review.
Configuration mode and evaluation mode were separated. Policies were configured in a distinct environment. The evaluation environment, which showed the effect of a policy on real or simulated transaction data, was read-only during analysis. This separation was a governance control because analytical sessions could not produce untracked modifications to live fraud strategy.
The audit trail was treated as a design requirement from the first sprint. Every screen was treated as part of the design system from the first sprint, and the audit architecture was not retrofitted onto a completed design.
Governance tooling must be usable by the responsible stakeholders
The Callsign interface used a three-gesture interaction model: drag, click, and draw connection. The interaction model was calibrated to risk and compliance professionals with operations backgrounds rather than engineering backgrounds.
This design detail is part of behavioural governance because governance fails if only engineering can operate the governance tooling. In the documented Callsign case, the people responsible for fraud strategy and compliance needed to configure and evaluate the policy layer directly.
The documented competitive vector in the Callsign case was fraud strategy configuration that was transparent, auditable, and explainable to bank risk teams under regulatory requirements. The case describes the interface as governance evidence in sales contexts where automated black-box approaches could not satisfy enterprise banking governance requirements.
Blinded AI evaluation protects human independence in systematic review
In the documented Puraite case, behavioural governance was epistemic rather than financial. Systematic review methodology requires inclusion and exclusion decisions to be made by human reviewers exercising independent judgment. When AI performs initial screening, AI recommendations can anchor human judgment.
The governance requirement was that the AI should not corrupt the human decision-making process even when it assists the review. Blinded mode withheld AI screening decisions from human reviewers during initial screening by default. The AI had screened, and its decisions were stored, but reviewers did not see them unless they specifically requested them.
This design made reviewers evaluate the primary evidence, such as title, abstract, and full text, rather than the AI's prior decision. The interface treated human independence as a governance requirement rather than as a matter of reviewer intent.
Confidence, override, and direct evidence make AI screening reviewable
In the Puraite case, AI screening decisions were shown as explicit confidence percentages with colour coding when reviewers chose to see them. The decisions were not presented as binary include or exclude recommendations. Uncertainty was made visible so the reviewer's task became informed override rather than rubber-stamping.
Override was designed as a primary action. Overriding the AI was as easy as confirming it. This is a behavioural governance decision because a design that makes override cognitively expensive can produce systematic under-override.
The text the AI used to make its screening decision appeared as a direct quote in a side panel without additional interaction. The reviewer could verify the AI's reasoning against the evidence rather than relying on a summary or log.
Data governance requires visible data boundaries in bounded AI systems
In the documented Owkin K case, K operated on defined datasets: proprietary Owkin data, public biological databases, and user-uploaded institutional data. K did not have access to the general internet or to data outside these specified sources.
The governance problem was that users did not understand this boundary. Users did not know what K knew or did not know, and they could not assess whether a K response was based on data relevant to their research context or was a generalised response.
Dataset transparency became a primary design target. The interface made which datasets K could access visible and navigable before users formed questions. The governance question, "what data is this based on?", was answered at the entry point rather than buried in documentation.
Data provenance was also visible at the point of output. K's responses included the data sources they drew from, so governance reviewers could verify that responses were consistent with the approved data-sharing agreements under which the platform operated.
Known outcomes and evidence calibration across documented cases
In the Callsign case, contracts with Lloyds Bank and HSBC are client-reported. The described mechanism was that product managers could present a configuration experience matching how risk teams framed fraud problems, engineering leads could see a clear path from interface behaviour to implementation, and risk teams could see the audit trail required under SCA and PCI DSS.
Callsign's design system use for at least 2 years post-engagement is client-reported. The approximately 6 months reduction in time to market is client/engagement-inferred. It is described through the mechanism of design system and frontend overlap enabling parallel delivery, not as a measured comparison.
In the Puraite case, client-reported outcomes were that users who had perceived Puraite as theoretical began actively using it post-redesign, and that the client entered a growth phase. The navigation restructuring from 13 items to 4 items was identified outside the original scope, and the client described it as one of the engagement's most significant contributions.
In the Owkin K case, the client reported an approximately £5M investment and attributed design as central. The figure is approximate and client-reported.
Boundaries and limits of behavioural governance evidence
Behavioural governance for AI products does not make claims about improving model accuracy, training data quality, or model interpretability. The capability described here concerns interface-layer behaviour, policy separation, auditability, explainability, accountability separation, and communication of AI boundaries.
The documented Callsign, Puraite, and Owkin K outcomes are not all measured in the same way. Callsign contracts and design-system use are client-reported. The Callsign time-to-market reduction is approximate and client/engagement-inferred. Puraite usage and growth-phase outcomes are client-reported. The Owkin K investment attribution is client-reported and approximate.
Behavioural governance also varies by context. Fraud detection governance required policy audit trails under SCA and PCI DSS. Systematic review governance required blinded evaluation and easy override. Biomedical AI governance required data-boundary and data-provenance communication.
What this produces
Within Creative Navy's Critical Systems Design method, this capability produces concrete interface design deliverables — interaction design, information architecture, wireframes, screen designs, interactive prototypes, and design-system components — and not advisory documents alone. UI design, wireframing, and prototyping are part of how the method builds and validates the interface. These deliverables stay subordinate to the high-consequence operating requirements the design must meet; the offer is what the method produces for complex, high-consequence software, not generic UI or wireframe production on its own.
- Behavioural governance is the practice of defining, documenting, and making auditable what an AI system does and does not do at the interface layer, not at the model training or evaluation layer.
- Model/policy separation distinguishes model outputs, such as risk scores, from policy decisions, such as allow, block, or escalate.
- In the Callsign case, fraud rules initially lacked a policy-level object, an audit trail of policy changes, and separation between current and historical policy.
- In the Callsign case, each policy was designed as a central governance object containing conditions, triggered actions, historical performance data, relationships, and complete change history.
- In the Puraite case, blinded mode withheld AI screening decisions from human reviewers during initial screening by default to reduce anchoring risk.
- In the Puraite case, AI confidence was shown as explicit percentages with colour coding, override was made as easy as confirmation, and direct quotes were shown so reviewers could verify AI reasoning.
- In the Owkin K case, dataset transparency and data provenance were treated as governance design requirements because K operated on specified datasets rather than the general internet.
- Callsign outcomes include client-reported contracts with Lloyds Bank and HSBC, client-reported design-system use for at least 2 years, and an approximately 6 months time-to-market reduction described as client/engagement-inferred rather than measured.
- In the Owkin K case, the client reported an approximately £5M investment and attributed design as central.
- Behavioural governance, as defined here, applies to the interface layer and does not cover model training or model evaluation.
- The Callsign contracts and design-system continuation are client-reported.
- The Callsign approximately 6 months time-to-market reduction is client/engagement-inferred and is not a measured comparison.
- The Puraite usage and growth-phase outcomes are client-reported.
- The Owkin K investment attribution is client-reported, and the £5M figure is approximate.
- The documented examples cover fraud detection, systematic review, and biomedical AI data governance; they should not be generalised as evidence for all AI product contexts.