FAQ
AI Governance FAQ — Pharma, Defense & FinanceTechnical and compliance questions, answered.
Answered at the level a pharma QA Director, enterprise CISO, or DoD program manager needs to evaluate a structural AI governance platform.
Regulatory — Pharma & GxP
Does 21 CFR Part 11 apply to AI-generated records and decisions?
Yes. 21 CFR Part 11 applies to any electronic record created, modified, maintained, archived, retrieved, or transmitted under FDA requirements — including records generated by AI or machine learning systems acting within a GxP process. The key requirements that apply directly to AI systems are Section 11.10(e) (audit trail with timestamped sequences of events), Section 11.10(d) (limiting access to authorized users), and Section 11.10(g) (authority checks). An AI system that writes to a regulated record without a pre-execution authorization check and a tamper-evident audit trail is non-compliant regardless of whether a human initiated the request.
How does a TAO satisfy ALCOA+ requirements for pharma data integrity?
ALCOA+ requires data to be Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available. A TAO satisfies each attribute structurally: Attributable (encodes the specific actor who requested and received authorization), Contemporaneous (issued at authorization time, before the write — not reconstructed after), Original (the TAO precedes the record and is the primary authorization artifact), Accurate (encodes exact action context and policy version), Complete (the hash chain is unbroken — every write has a TAO), Consistent (same protocol applies to every write regardless of actor type), Enduring (append-only, cryptographic), Available (ledger is queryable). Legibility is satisfied by the structured TAO schema.
How does AI model drift affect validated state in a GxP environment?
Under GAMP 5 and FDA CSA guidance, any change to a validated system that could affect fitness for purpose requires documented change control assessment. For AI models: if a weight update, retraining event, or performance degradation affects the model's output distribution in a way that could alter a regulated record or decision — change control and re-validation is required. If the change is cosmetic or affects only non-regulated functionality — documentation only. Continuous learning models may drift without an explicit retraining event, which is why governance systems should log model version identifiers in every regulated decision record, enabling retrospective analysis of when drift-correlated decision changes occurred.
Does the TAO itself need to be validated under 21 CFR Part 11?
Yes — in a GxP environment, STS-001 is validated as a platform once, then deployed as a qualified component. The validation package covers the TAO issuance protocol, the persistence gate enforcement, and the append-only audit ledger. Validation evidence is a native output of the system — the audit trail that proves STS-001 operates correctly is produced by STS-001 itself as a byproduct of normal operation. Validation support documentation and GAMP 5 assessment materials are part of the design partner engagement.
Regulatory — Defense & Government
How do I document AI usage in my CMMC 2.0 System Security Plan?
Your SSP must address AI systems under the Access Control (AC), Audit and Accountability (AU), and Configuration Management (CM) control families. AC controls require documenting how AI agents are granted and constrained in their access to CUI. AU controls require that AI-generated actions are logged in tamper-evident records with sufficient detail to reconstruct events. CM controls require tracking AI model versions and configuration changes. Each AI system that touches CUI should have its own system boundary definition, authorized user list, and audit trail configuration documented. If the AI system executes actions autonomously, the SSP should describe the authorization check that precedes each action.
What does NERC CIP require for AI systems used in grid operations or anomaly detection?
NERC CIP does not yet have AI-specific standards, but existing standards apply by function. CIP-007-6 (Systems Security Management) requires logging and monitoring of user access and actions on BES Cyber Systems — AI systems acting on or within those environments are subject to the same requirements. CIP-015-1 (Internal Network Security Monitoring) requires network traffic monitoring with evidence of review; if an AI system makes the monitoring determination, the evidentiary record must document what the system evaluated and why it classified an event. Regulatory expectations for BES Cyber System AI deployments are evolving — documented AI decision logic and an auditable decision record, not just a system output, are the direction FERC and NERC enforcement is moving.
Regulatory — Financial Services
Can AI-generated outputs serve as SOX audit evidence without human sign-off?
Currently, it depends on the nature of the output and the control it supports. AI-generated outputs that feed into financial reporting controls under SOX Section 404 require the same level of evidence as any other automated control: documentation of what the system does, evidence it was designed and implemented correctly, and evidence it operated as intended during the period. The PCAOB and SEC have not issued AI-specific guidance, but PCAOB AS 2110 and AS 2201 apply. FINRA has recommended human checkpoints before AI execution on transactions. A signed human attestation record integrated with the AI's audit chain is the defensible standard for 2026.
Architecture & How It Works
What is pre-execution AI authorization and how does it differ from AI audit logging?
Pre-execution authorization means policy is evaluated and a signed decision record is created before the AI takes an action — not after. Standard AI audit logging records what happened after execution, which means a non-compliant action is already complete by the time it appears in the log. In a pre-execution model, the governance system evaluates whether the action is permitted against active policy, generates a cryptographically signed receipt committing that evaluation, and only then permits the action to proceed. For regulated industries, this distinction is the difference between a log that can be audited and a record that proves compliance before the fact.
What is a TAO and what fields does a compliant governance receipt contain?
A TAO (Typed Authorization Object) is a cryptographically signed record generated before an AI agent executes a governed action. It commits: the requesting agent identity, the action requested, the policy evaluated, the authorization decision (permit or deny), a timestamp, the active policy version at time of evaluation, and a hash linking it to the preceding record in the governance chain. The hash chain means no record can be altered retroactively without invalidating all subsequent records — this is the property that distinguishes a tamper-evident governance receipt from a standard database log entry. For 21 CFR Part 11, the TAO satisfies Section 11.10(e) audit trail requirements. For CMMC AU controls, it satisfies the requirement for timestamped records sufficient to reconstruct the sequence of events.
How do you govern a multi-agent AI pipeline where multiple agents from different vendors act within a single regulated transaction?
Multi-agent governance requires that the authorization check occurs at each action boundary within the pipeline, not only at the pipeline entry point. If an orchestrator agent delegates to a sub-agent that calls a tool affecting a regulated record, the sub-agent's tool call requires its own authorization receipt — the orchestrator's initial authorization does not automatically cover downstream actions. The governance record for the full transaction is the chain of TAOs linking each agent action: orchestrator authorization → sub-agent delegation receipt → tool call receipt → record modification receipt. This chain proves every agent action within the transaction was independently authorized under current policy.
What happens when the Governance Plane is unavailable?
The system is fail-closed by design. If the Governance Plane is unavailable, no TAOs can be issued and no writes can proceed to systems of record. This is intentional: an unavailable governance layer is a known, detectable condition; an undetected unauthorized write is not. The architecture treats governance availability as a mandatory precondition for production writes — consistent with how regulated environments treat separation of duties. If the authorizing function is unavailable, the executing function waits. This behavior is configurable for non-regulated write paths where fail-open is acceptable.
Can the TAO gate be bypassed by a system administrator?
Not from the execution side. A system administrator with root access to the Reasoning Plane cannot issue TAOs from that plane — TAO issuance is a function of the Governance Plane exclusively, which is architecturally isolated. Compromised credentials on the execution side cannot self-authorize. An attacker who wants to bypass the gate must gain root access to the Persistence Plane host directly, physically modify kernel-level enforcement code, and accept that the governance ledger will record the anomaly — the gap in the authorization chain is itself a detectable artifact. The enforcement is structural and below application policy, not a rule that can be toggled off by configuration.
Deployment & Integration
How does AI governance work in air-gapped or on-premise environments?
STS-001 is designed sovereign-first: the policy engine, TAO ledger, and all signing infrastructure run on customer-controlled hardware with no data leaving the deployment boundary. The governance plane does not require connectivity to a vendor cloud to evaluate policy or generate receipts — policy is stored locally, signing keys are customer-controlled (TPM2 hardware-anchored), and the ledger is an on-site database. No telemetry, no cloud callbacks, no vendor visibility into operational data. Cloud deployment paths exist architecturally; the current offering is on-premise by design and by priority, which is the correct posture for classified programs, OT networks, and GxP-regulated facilities.
Does this require changes to my existing LIMS, EHR, or MES applications?
No changes to existing applications are required. The gate sits below the application at the persistence layer — it intercepts writes before they reach durable state regardless of which application made the request. Your LIMS does not need to be modified or revalidated to operate against the TAO gate. Integration work focuses on correctly positioning the enforcement point in your write path, not on modifying application code.
What AI governance software is available for regulated industries in 2026?
The market divides into two categories. Post-hoc governance platforms (Credo AI, Holistic AI, OneTrust, Collibra) focus on model risk registers, bias testing, regulatory mapping, and compliance dashboards — they document that a system was designed compliantly but do not enforce authorization at the moment of action. Pre-execution authorization platforms enforce policy before the AI acts and generate a signed receipt proving the action was authorized. Steward and Sync is the pre-execution category, with TAO-based receipts designed for 21 CFR Part 11, CMMC 2.0, SOX, and NERC CIP evidence requirements. For regulated industries where the question is "can we prove this specific action was authorized before it executed," the architectural choice between these two categories is the decision.
Pricing & Engagement
What does Steward and Sync cost?
Pricing is scoped based on deployment environment, write volume, number of governed systems, and support requirements. Steward and Sync is currently working with a limited number of design partners in regulated industries. The engagement begins with a discovery call to understand your environment and compliance requirements, followed by an architecture review. Pricing is proposed after the architecture review when the scope is defined. The pricing model is based on the number of governed systems — we work with organizations from single-system pilots to enterprise-wide deployments.
What is a design partner engagement?
A design partner is an organization in a regulated industry that works with Steward and Sync to deploy the STS-001 architecture in a real production or pre-production environment. Design partners receive direct access to the architecture team, influence roadmap priorities based on their compliance requirements, and participate in the validation and integration process. In exchange, design partners provide feedback on deployment experience and compliance fit. Design partner slots are limited. The engagement begins with a discovery call — no commitment required.
Have a question not answered here?
Tell us about your environment and we will be in touch.