14. Building AI Systems Honestly: The Gap Loop, What Works, and the Protocol That Emerged

---

The 14-Article Journey Leads to One Verification Question

The series moves from architecture through security, data, and governance. This final article connects those topics with one question: what evidence shows that a capability works in its intended workflow?

Article	Focus	Continue reading
1	Multi-agent architecture	From Monolith to Multi-Agent
2	Orchestration and stack	The Engineering Platform
3	Audit and what “done” means	The 57-Gap Audit
4	Authentication and authorization	Securing Agentic AI
5	Red-team probes	Red-Teaming AI
6	Audit trails and policy-as-code	Compliance Infrastructure
7	Human-in-the-loop checkpointing	Building Real Human-in-the-Loop
8	Data pipelines and vector search	Data Engineering for AI Agents
9	Synthetic data provenance	Synthetic Data Governance for AI
10	Agentic model risk and observability	Model Risk and the Observability Gap
11	Fairness, explainability, and drift	Fairness, Explainability, and Drift
12	Threat modeling	Threat Modeling AI Systems
13	ISO 42001 governance	ISO 42001 in Practice

For another perspective on building agents with external tools, see tool integration in Agentic AI Engineering.

Where AI Assistance Accelerated the Work

AI assistance helped scaffold a five-agent platform and supporting services. At the same time, the generated code still needed integration and verification.

The platform includes an orchestrator and credit, Sharia, risk, and simulation agents. AI assistance helped scaffold services, routers, data pipelines, and models; integration checks still had to show that components exchanged real data and enforced controls.

For more detail on the design behind that platform, revisit the shift from a monolith to multi-agent architecture and the orchestration, monorepo, and stack decisions.

Generated framework code and regulatory references also needed review against applicable requirements and the controls actually in place. Treat generated structure as a starting point, not validation.

Back to top · Next: The Declaration Gap

---

🔴 AI-Generated Code Verification and the Declaration Gap

AI-generated code verification starts by checking whether a capability actually runs in its intended workflow. A successful build or type check does not show that the path ran.

Project records describe Langfuse running without model-call traces and an audit-events table receiving no rows. These gaps became visible by checking runtime evidence, not just confirming that a service or table existed.

Security claims also need evidence at each boundary: authentication, authorization, and personal-data handling should be tested alongside red-team probes for AI-specific threats. Threat modeling helps identify which boundaries and abuse cases those checks need to cover.

Five Patterns That Create a Declaration Gap

1. Cosmetic compliance: a requirement is documented, but no runtime check enforces it.
2. Disconnected pipeline: a data product exists, but the consuming service does not use it.
3. Shallow completeness: components exist, but live data or end-to-end execution is missing.
4. Single-layer security: one boundary enforces access while another remains unprotected.
5. Hardcoded governance: policy thresholds live in code instead of governed configuration.

As a result, hardcoded thresholds are difficult to change through a controlled approval process. Keep policy values in a governed configuration source, with an owner and an auditable change history.

More broadly, these patterns can occur in any fast-moving software project. AI can make them harder to notice when generated code looks complete before its paths have been exercised.

Back to top · Next: The Audit

---

The Audit Produced a 51-Item Code-Gap Register

The code-gap register contained 51 findings across five areas: code quality, model and responsible-AI governance, security, audit and monitoring, and compliance documents.

This audit follows the series’ earlier examination of what “done” means in a production AI gap audit; the register below summarizes the findings covered by this capstone.

Audit area	Representative finding
Code quality	Duplicated helpers and business thresholds embedded in code
Model and responsible-AI governance	Missing processing records and unpopulated Sharia Board review fields
Security	Unenforced tool permissions and disconnected quarantine handling
Lineage, audit, and monitoring	Audit events not reaching the database; monitoring evidence absent
Compliance documents	Missing NIST AI RMF risk matrix and governance policy

The audit records all 51 register items as closed. That result applies to the code-gap register; it is separate from ISO readiness, certification, and evidence of ongoing operation. For the controls behind audit trails and policy-as-code, see the series article on compliance infrastructure.

The register records remediation of its listed findings; it does not establish that every control remained effective in a live deployment.

The ISO/IEC 42001 Readiness Review

A self-assessment against the ISO/IEC 42001 standard considered technical-control coverage and governance-documentation coverage. A separate readiness register tracked management-system criteria, live operational evidence, and human sign-offs. These are distinct measures; neither is a certification result. The series’ ISO 42001 governance article explores the documentation and evidence behind that review.

Writing governance documents also exposed implementation questions: an accurate policy must describe what the controls actually enforce. Reviewing the policy against the authorization rules therefore served as both documentation work and a control review.

Back to top · Next: The Gap Register

---

📋 The Gap Register as Primary Artifact

A gap register records the difference between a declared capability and the evidence that supports it.

Unlike a feature backlog, each entry names the claim, expected behavior, evidence checked, observed gap, priority, owner, and next verification step. For broader guidance on identifying and documenting AI risks, see the NIST AI Risk Management Framework. Then make an entry concrete: replace “fairness monitoring” with the specific output or job result that is missing. The discoverer records the gap; its owner updates status and evidence.

For examples of the model-risk and observability questions behind those checks, read the article on agentic model risk and the observability gap, alongside its companion on fairness, explainability, and drift in production.

Set review frequency by risk and policy. An independent reviewer checks evidence against the closure condition; the control owner approves closure. Record risk acceptance separately, with an authorized approver, rationale, and next review point.

AI-Generated Code Verification: A Repeatable Loop

In practice, an engineer and reviewer can repeat this short evidence loop:

1. State the claim. Name the capability, workflow, expected result, and owner.
2. Run the path. Capture a relevant test, trace, audit row, or event with its environment and build reference. For a security control, test both allowed and denied cases.
3. Record the gap. Describe the observed result, impact, priority, owner, closure condition, and next check. A code class or configuration entry alone is not evidence that the path ran.
4. Verify and decide. Rerun the path after a change. An independent reviewer checks the evidence; the control owner approves closure. Record accepted risk separately with an authorized approver and next review point.

Evidence Must Match the Claim

Match evidence to the claim. A trace proves that an instrumented call was recorded; it does not prove that the model response was correct. Likewise, a passing test covers only the cases it exercises. Keep the test inputs, expected and observed results, environment, build or commit, and limits with the finding; link to access-controlled, sanitized artifacts rather than copying sensitive records into the register.

Claim	Evidence to collect	What to review
Model calls are traced.	Run a representative workflow and inspect the resulting trace.	Confirm the call appears with the expected service and time; review response quality separately.
Audit events persist.	Trigger the workflow and check its database record and any downstream event.	Verify persistence and delivery as separate steps.
Access is enforced.	Test both an authorized and unauthorized request.	Check the boundary response and the security record.
Human review blocks completion.	Exercise escalation, timeout, and an authorized resume decision.	Confirm the pending state, reviewer identity, and final decision are recorded.

An empty audit table calls for a workflow test that checks the expected record, not just confirmation that a logger imports. For scheduled controls, review job history and alert routing as well as a successful run.

Back to top · Next: The Rebuild

---

Remediation Changed the Workflow and Data Path

The follow-up work changed both implementation paths and the evidence used to review them.

Follow-up work changed human review to save an interruption and resume only after an operator decision; a timeout monitor records expired reviews as timeouts. A person still owns the decision and must assess the evidence. The implementation connects to the series’ human-in-the-loop checkpointing example.

Connecting the credit agent to prepared Gold-layer data made the pipeline-to-agent handoff reviewable. The series’ data-engineering article on pipelines and vector search provides more context on that flow; its companion on synthetic-data governance and provenance addresses how to document data origins. Readers can also continue with the Agentic Data Platform’s synthetic-data engineering article. For regulated decisions, record which source and calculation changed.

Treat code-gap closure and ISO readiness as separate records: they answer different questions and use different scopes. When reporting readiness, name the criteria measured and the evidence behind the result.

Back to top · Next: The Practices

---

Practices for AI-Generated Code Verification

Taken together, these practices turn model-risk and AI-management guidance into checks for AI-assisted software work. NIST’s AI Risk Management Framework and ISO/IEC 42001 provide broader risk and management-system guidance; the steps below focus on verifying implementation claims.

1. Read before writing. Inspect the code, data flow, and configuration before adding another implementation.
2. Verify the workflow. Capture a trace, database record, or test result that demonstrates the claimed path.
3. Make ownership visible. Record the finding, priority, owner, evidence, and next check.
4. Choose evidence for the response. Use logs for investigation, metrics for trends, audit records for review, or messages for downstream action.
5. Reuse established patterns. Check existing helpers and approved tools before building a new path.

Keep Decision Records, Costs, and Tool Choices Visible

1. Keep an append-only decision history. Record what changed and why, including corrections and review decisions.
2. Manage AI usage costs. Track token use and avoid repeated broad reads or unnecessary agent work.
3. Evaluate alternatives before building custom. Match tools to the required lifecycle, hosting, and regulatory needs, and keep the evaluation record.

For agent frameworks and deployment patterns, compare orchestration, hosting, approvals, audit needs, and lifecycle requirements. The Agentic AI Engineering series offers a complementary implementation example.

Back to top · Next: What 14 Articles Add Up To

---

What 14 Articles Add Up To

The series moves from architecture and declared controls through audit, remediation, and a more disciplined approach to evidence.

Across architecture, security, data provenance, human oversight, model risk, threat modeling, and governance, the conclusion is the same: state what the system should do, exercise the workflow, compare results with the claim, assign an owner to any gap, and verify the follow-up. That practice applies whether code comes from a person, an AI assistant, or both.

AI-generated code verification makes completion an evidence-backed decision: show the expected behavior in its intended workflow, state what the evidence cannot establish, and identify who approves the result.

Back to top

---

---