Most executives in regulated industries have already approved some form of artificial intelligence.
Maybe it is helping employees search internal documents. Maybe it is summarizing clinical records, identifying maintenance risks, prioritizing cases, generating software, or supporting operational decisions.
The first boardroom question was predictable:
Does the AI work?
The next question is much less comfortable:
Can we account for what it did?
Not with a product demonstration. Not with a colorful dashboard and three cheerful green checkmarks. On paper. During an audit. In litigation. After the employee who configured it has left the company and the vendor account representative has stopped returning calls.
For many enterprise AI deployments, the honest answer is still no.
That is the governance gap boards are beginning to notice.
The Market Has Moved From Experimentation to Accountability
Federal AI policy is no longer built around vague encouragement to “explore responsible AI.”
The operational requirements have arrived.
OMB Memorandum M-25-21 requires federal agencies to maintain AI use-case inventories, publish compliance plans, establish governance responsibilities, and apply defined risk-management practices to high-impact AI. The major implementation deadlines fell between September 2025 and April 2026, but the obligations did not disappear when the calendar rolled over. Inventory maintenance, oversight, reporting, testing, and risk management are continuing responsibilities.[1]
In other words, this is no longer a future compliance problem.
It is Tuesday.
Federal contractors and technology providers are not all directly subject to one universal AI deadline. The pressure reaches them through a different door: procurement.
OMB Memorandum M-25-22 directs federal agencies to consider documentation, testing, monitoring, data rights, intellectual property, interoperability, portability, pricing transparency, and vendor-lock-in risk when acquiring AI systems.[2] Those expectations increasingly appear in solicitations, technical evaluations, contract clauses, and performance requirements.
That distinction matters. Contractors are not being handed one giant federal compliance checklist. They are being asked to prove, contract by contract, that their systems will not become an expensive black box with a government logo taped to the front.
Procurement itself is also moving faster in some areas. Other Transaction agreements, SBIR pathways, cooperative purchasing vehicles, and certain sole-source authorities can reduce acquisition timelines when their statutory requirements are met. Texas DIR contracts similarly allow eligible public entities to purchase through pre-negotiated vehicles rather than beginning every acquisition from scratch.[3]
These mechanisms do not eliminate scrutiny.
They compress it.
A vendor may have weeks rather than months to explain where the data resides, who can change the model, how human approvals are enforced, what happens when a control fails, and whether the customer can leave without losing its own history.
That is not a great moment to discover that the governance plan is a slide deck.
The Real Risk Is Not Just the Model
Most enterprise AI platforms were originally built to ingest data, run models, and produce outputs. Governance often arrived later through policy layers, reporting modules, access-control screens, and audit dashboards.
Those features can be useful. The problem is assuming their existence proves the underlying system is governable.
A dashboard can show what the platform chose to record. It cannot prove that every consequential action was required to pass through the controls shown on the dashboard.
That difference sounds technical until something goes wrong.
Suppose an auditor, regulator, investigator, or plaintiff’s attorney asks why an AI-assisted decision was made on a particular date. The organization may need to reconstruct:
- What data entered the decision
- Which version of the model or workflow was used
- What instructions and policies were active
- Which tools or external systems were called
- Whether the output was changed
- Who reviewed or approved it
- Whether any control was bypassed
- What happened after the decision
“We have logs” is not yet an answer.
Which logs? Controlled by whom? Can they be altered? Can they be exported? Do they capture the complete transaction or merely the final output? Would the records still be intelligible two years from now?
Dashboards are lovely. Depositions are less easily impressed.
ISO/IEC 42001 Raises the Organizational Bar
ISO/IEC 42001:2023 is the first international management-system standard specifically focused on artificial intelligence. It defines requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System, or AIMS.[4]
The standard addresses issues such as accountability, risk assessment, documented responsibilities, lifecycle management, monitoring, impact evaluation, and continual improvement.
It does not prescribe one universal technical architecture. Nor does it require a human to manually approve every AI-generated sentence. Controls must be proportionate to the organization, the use case, and the risk.
Still, the direction is clear.
AI governance cannot remain a policy document stored in the same folder as the annual cybersecurity training certificate.
Organizations must be able to show how policy becomes execution.
Who owns the risk? Where is the system inventory? How are high-risk uses classified? What evidence shows that controls operated? How are incidents handled? How does the organization know when a model, prompt, data source, permission, or workflow has changed?
Those questions are management questions, but they have architectural consequences.
A policy may say that high-impact decisions require human approval. The system must then prevent the decision from being executed without that approval.
A policy may say that access can be revoked. The infrastructure must ensure that cached permissions do not quietly outlive the revocation.
A policy may require traceability. The system must record enough context to reconstruct what happened without depending on the memory of the person who built it.
Governance becomes real only when the architecture makes noncompliance difficult.
Data Provenance Is Becoming a Core Control
Every important AI output begins with evidence.
That evidence may include a database record, clinical note, sensor reading, maintenance history, image, policy document, email, user instruction, or retrieval result. During processing, it may be cleaned, transformed, summarized, combined, ranked, or filtered.
If the organization cannot trace those transformations, it cannot fully explain the result.
Sound provenance practices should establish:
- Where information originated
- When it was collected or retrieved
- Which transformations were applied
- Which version was used
- Whether the source changed
- How integrity was verified
- Which decision relied on it
In high-risk environments, provenance records should also be tamper-evident. That may involve append-only storage, cryptographic hashing, hash chaining, signed records, independently controlled keys, restricted administrative privileges, immutable retention systems, or external verification.
A conventional database entry is not automatically immutable simply because everyone agrees not to edit it.
Databases, much like toddlers and junior developers, are technically capable of doing several things you told them not to do.
The control must be enforced and verifiable.
Recent research into clinical AI has explored combining retrieval-augmented generation with provenance and tamper-evident logging so that generated recommendations can be traced back to specific evidence.[5] These approaches are promising, although many remain conceptual or require further real-world validation.
The larger point is already settled: an AI answer without a traceable evidence path is difficult to defend in a safety-critical environment.
Healthcare Makes the Problem Obvious
Consider a hospital deploying AI inside an Epic or Oracle Health workflow.
Depending on the use case, the system may need to work with structured patient records, clinical notes, laboratory results, medications, imaging, policies, and prior encounters. It may also need to distinguish between authoritative clinical evidence and material that is merely plausible.
That is not a simple chatbot problem.
It is a controlled evidence problem.
HIPAA does not universally require healthcare organizations to keep protected health information off public or vendor-operated cloud infrastructure. HHS permits the use of cloud services when the appropriate business-associate agreements, safeguards, risk analysis, and compliance controls are in place.[6]
Still, many healthcare organizations may choose customer-controlled, private-cloud, hybrid, or on-premises deployment because of security policy, contractual obligations, latency, resilience, data-residency concerns, or institutional risk tolerance.
The governance question is not merely, “Is cloud allowed?”
It is:
Who controls the data, the records, the keys, the evidence, and the exit?
If a clinical AI system produces a recommendation, the hospital should be able to identify the supporting sources, model and workflow version, human-review status, and resulting action.
The decision record should not evaporate when the subscription ends.
Railroads Face a Different Version of the Same Problem
Rail operations involve dispatching, maintenance, inspection, signaling, asset health, crew activity, and safety-sensitive decisions made across a large physical network.
AI may help predict failures, prioritize inspections, identify anomalies, or support dispatch and maintenance planning. The applicable Federal Railroad Administration requirements will depend on the system and operational context. There is not one universal regulation requiring a dedicated AI record for every prediction.
There is, however, a practical reality.
When an AI-assisted recommendation influences a safety-relevant action, the railroad may later need to explain what information was available, how the recommendation was produced, who acted on it, and whether required operating procedures were followed.
The records must remain complete, accessible, and intelligible to the railroad—not merely retrievable at the vendor’s convenience.
That makes sovereign and edge deployment attractive in certain rail environments. Connectivity is not always guaranteed. Operational continuity matters. So does control over the decision history.
Vendor lock-in has a remarkable ability to stop looking like convenience once general counsel enters the room.
Three Things Regulated Organizations Should Do Now
1. Inventory the AI Before Someone Else Does
Document every meaningful AI use case.
Include internally developed systems, vendor products, embedded features, departmental experiments, automated decision tools, generative assistants, and AI functions hiding inside software the organization already owns.
For each use case, identify:
- The business owner
- The technical owner
- The purpose
- The affected population
- The data involved
- The model or service used
- The risk level
- The human-oversight mechanism
- The location of the decision record
- The vendor and contractual dependencies
Do not limit the inventory to systems formally purchased by IT. Unapproved AI has a habit of appearing wherever employees have a browser and a deadline.
2. Separate Computation From Custody
The system that performs an inference does not necessarily need permanent custody of the organization’s data and audit history.
Organizations should decide deliberately where the following assets reside:
- Source data
- Prompts and instructions
- Model configurations
- Retrieved evidence
- Approval records
- Tool-call histories
- Audit logs
- Cryptographic verification records
- Final decision artifacts
Customer-controlled storage can make it easier to preserve evidence, apply organizational retention policies, integrate with existing security controls, and migrate between model providers.
It also reduces the risk that the customer technically owns the data but cannot meaningfully use it without the vendor’s software.
That is ownership in the same way a hotel guest owns the clothes locked in a room after checkout.
3. Map the Exit Before Signing the Entrance
Exit planning is governance.
Before deployment, the organization should know whether it can export its data, configurations, audit records, model history, decision artifacts, and supporting evidence in usable formats.
Ask uncomfortable questions early:
- Can another system verify the audit chain?
- Are schemas documented?
- Can the organization reproduce a historical decision?
- Does the vendor retain proprietary control over critical metadata?
- What happens to logs after termination?
- Can the organization operate during a transition?
- Are model and data portability addressed contractually?
- Is the migration path tested or merely promised?
Per-seat pricing may be annoying. Dependency on an inaccessible decision history is considerably worse.
How Tigunny Conflux Approaches the Problem
Conflux was designed around the idea that governance should be part of the execution path, not a report generated after the fact.
The platform is built to produce a traceable artifact trail for AI-assisted work. Actions, approvals, evidence, model interactions, and decision records can be captured as the workflow occurs.
The audit-chain design uses PostgreSQL as an open and portable data foundation, combined with append-only controls and cryptographic hash chaining to make unauthorized changes detectable. The objective is not to claim that a database is magically immutable. It is to create a decision history whose integrity can be independently verified.
That distinction matters.
Conflux is also vendor-agnostic by design. Organizations can use different commercial, open-weight, local, or hosted models without making one model provider the permanent owner of the governance record.
The models may change.
The accountability chain should not.
For healthcare deployments, Conflux is designed to coordinate structured records, unstructured notes, retrieved evidence, and other authorized clinical inputs while allowing the organization to determine where sensitive data and audit artifacts are stored.
For transportation and rail environments, the platform supports customer-controlled and edge-oriented deployment patterns where connectivity, resilience, and local custody matter.
For government agencies and contractors, Conflux is designed to support evidence production for inventories, risk reviews, human approvals, model activity, and audit reconstruction.
Tigunny is an SBA-certified Service-Disabled Veteran-Owned Small Business, a Texas-certified Historically Underutilized Business, and an active SAM.gov registrant. Those credentials can support access to relevant federal, state, prime-contractor, and subcontracting opportunities. They do not automatically guarantee an award or create eligibility for every acquisition pathway.
Procurement still requires evidence.
Frankly, that is the point.
The Decision in Front of the Board
The next phase of enterprise AI will not be defined only by better models.
Models will improve. Prices will change. Vendors will consolidate. New capabilities will appear, usually five minutes after the annual budget is approved.
The durable question is whether the organization controls the decision system around those models.
Can it identify every material AI use case?
Can it explain how a high-impact output was produced?
Can it prove that required controls were applied?
Can it preserve the record?
Can it change vendors without losing its institutional memory?
Can it answer those questions without asking the vendor for permission?
Boards should stop asking only whether AI creates value. They should ask whether the organization can defend that value after the demo is over.
Because the most expensive AI system is not necessarily the one with the highest license fee.
It is the one you cannot explain, cannot move, and cannot turn off without losing the record of what it did.
To discuss what defensible AI governance could look like in your environment, contact info@tigunny.com to schedule a Conflux architecture review.
References
- Office of Management and Budget. (2025). M-25-21: Accelerating Federal Use of AI through Innovation, Governance, and Public Trust.
- Office of Management and Budget. (2025). M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government.
- U.S. Government Accountability Office. (2017). Federal Acquisitions: Use of Other Transaction Agreements Limited and Mostly for Research and Development Activities. Texas Department of Information Resources. Cooperative Contracts Program materials.
- International Organization for Standardization. (2023). ISO/IEC 42001:2023—Information technology—Artificial intelligence—Management system.
- Alu, F. F., & Oluwadare, S. (2026). An auditable and source-verified framework for clinical AI decision support: Integrating retrieval-augmented generation with data provenance. Frontiers in Artificial Intelligence, 9, 1737532.
- U.S. Department of Health and Human Services. Guidance on HIPAA and Cloud Computing.
- Mateo-Casali, M. A., et al. (2026). Reference architecture for the design and implementation of AI systems in manufacturing in conformity to ISO/IEC 42001. International Journal of Computer Integrated Manufacturing.
- Młodawski, A., & Wolniak, A. (2025). Lightweight AI Governance Framework for SMEs. Proceedings of TRUST-AI 2025, 209–215.
- Surve, P. P., Shabtai, A., & Elovici, Y. (2026). CEDAR-42001: From ISO/IEC 42001 conformity to architecture-aware, audit-visible assurance posture for AI cyber-physical systems. arXiv preprint.