Operational systems produce the record
Identity, device, ticketing, engineering, HR, and quality systems show what actually happened.
Building practical AI-powered compliance systems.
I design and build practical AI-powered compliance systems. My work connects compliance requirements to operational data, automates repetitive workflows, and helps security, IT, and engineering teams understand—not just document—their compliance posture. The goal is simple: spend less time chasing evidence and more time improving systems.
A living compliance model
IdentityDevicesTicketsCode
Control modelWhat is true?Signals are connected to controls, evidence, and exceptions.
Evidenceready for review
Exceptionowner identified
Answercontext included
The Problem
Compliance is disconnected from operational reality.
Most compliance work starts after the operational work has already happened. Teams collect screenshots, export reports, copy answers between systems, and rebuild context for every audit cycle.
The evidence already exists. It is usually spread across identity, device, ticketing, security, engineering, HR, and quality systems. The missing layer is a model that connects that operational data to controls, evidence, exceptions, and review.
- Evidence lives in tools auditors do not use.
- Controls are described separately from the systems that satisfy them.
- Reviews happen after the work, instead of alongside it.
The Idea
Compliance should emerge continuously from operational systems.
Compliance should not be a separate reporting activity. It should be the observable result of healthy operational processes, connected to a model that both automation and people can inspect.
Controls interpret the record
Requirements become checks, evidence mappings, exceptions, and review paths tied to real system behavior.
Automation keeps the model current
Agents collect context, explain findings, and recommend actions while people remain accountable for decisions.
The Architecture
Systems become useful when they share a compliance model.
The architecture is simple: operational systems feed a platform, the platform gives agents a reliable model to work against, and people review the decisions that require judgment.
Systems
HRISIdentityAsset MgmtMDMEDRTicketingQMSCloud
Platform
NormalizeCorrelateEvaluateMonitor
Agents
CollectAnalyzeExplainRecommend
People
EngineeringSecurityITQualityAuditors
The Ingredients
A working compliance system needs five things.
The architecture only works when data, controls, automation, and accountability reinforce one another. Remove one of these parts and the system drifts back toward manual evidence collection.
01
Continuous Compliance
Modern compliance should not depend on quarterly scrambles or screenshot hunts. The systems should know what changed, what needs review, and what evidence already exists.
- Device coverage monitoring
- Training and lifecycle exceptions
- Vulnerability and asset-return workflows
02
Operational Data
The hard part is not connecting APIs. It is creating a canonical representation of compliance state from messy operational systems.
- HRIS and identity correlation
- Asset and owner mapping
- Ticketing and control evidence alignment
03
AI Agents
Agents are most useful when they operate against a shared model. They can collect, analyze, explain, and recommend without pretending to own the decision.
- Auditor question answering
- Evidence retrieval
- Drafted control responses
04
Control Evaluation
Controls become more valuable when they are connected to system behavior, exception handling, and review outcomes.
- Automated checks
- Exception queues
- Control-aligned records
05
Human Oversight
Automation should make accountability clearer, not blur it. People still approve evidence, own remediation, and decide what risk means.
- Review workflows
- Evidence approval
- Engineering, security, IT, quality, and auditor collaboration
Representative Projects
Standards become useful when they are connected to operating systems.
These projects show how compliance guidance can be translated into data models, agent skills, evidence workflows, and documentation that people can inspect.
Operational controls connected to evidence workflows
- Problem
- Control descriptions and audit requests were separated from the operational data that could answer them.
- Architecture
- Mapped operational controls to a shared data warehouse, then gave agent skills access to the model and its source records.
- Outcome
- Evidence requests could be populated from current system data with traceable context for human review.
Data warehouseControl mappingEvidence requestsAgent skills
Engineering systems made visible to quality workflows
- Problem
- Quality and validation records needed to reflect how engineering tools were configured and used in practice.
- Architecture
- Applied ISO 9001 processes in support of GxP requirements and built agent skills that report on the engineering toolset.
- Outcome
- Produced supporting validation documentation with a clearer connection between engineering activity, quality processes, and review.
Quality systemsGxPValidationEngineering data
Continuous reporting aligned to the system security plan
- Problem
- The assessment scope, operational systems, and System Security Plan needed to describe the same security boundary.
- Architecture
- Aligned systems and control ownership to the CMMC Level 2 scope, then used agent dashboards to report continuously on implementation state.
- Outcome
- The System Security Plan could be maintained with current operational context, visible gaps, and clearer support for assessment preparation.
CMMCSSPScopeAgent dashboards