Kyūdō
Definition

What Is an AI-Native GRC Platform?

An AI-native GRC platform is a governance, risk, and compliance system in which AI is the operating substrate: it reasons over governed, connected compliance data instead of being a chatbot bolted onto static records. Every answer traces back to evidence with a hash, lineage, and confidence score, and queries below the confidence threshold go to a human.

Kyūdō is an AI-native Governance, Risk, and Compliance platform for regulated organizations that need to automate evidence collection, map controls across frameworks, manage vendor risk, govern AI risk, and produce audit-ready proof from Microsoft security data. It deploys inside the customer's own Azure tenant, and this page explains what makes that architecture different. See the platform overview for the full module map.

Book a Deployment WorkshopSee Continuous Proof in Action
The Gap

Why traditional GRC is not enough

Traditional GRC tools were built as systems of record: places to file controls, upload evidence, and track assessment dates. That design has three structural limits that no amount of added AI chat can remove.

Disconnected records

Controls, risks, policies, and vendor assessments live in separate modules or spreadsheets. When a control fails, nothing tells you which risks, frameworks, or vendor relationships are affected.

Point-in-time assessments

Evidence is gathered for the audit window, then goes stale the day after. Between assessments, posture is assumed rather than observed.

Manual evidence collection

Teams export screenshots and configuration dumps by hand, then repeat the work for every framework. The effort scales with the number of obligations, not the size of the estate.

For a side-by-side view of the two models, see Kyūdō vs. traditional GRC.

The Mechanism

How Kyūdō uses AI with governed evidence

AI is only as trustworthy as the data it reasons over and the guardrails around its output. Kyūdō pairs the Compliance Graphwith four mechanisms, and all inference runs on Azure OpenAI Service inside the customer's tenant. Read how the customer-hosted architecture keeps the entire loop in your environment.

Deterministic retrieval

Sensei AI Advisor does not free-associate. It retrieves from the Compliance Graph, a governed data layer, so the same question over the same data returns the same grounded answer.

Citations to source nodes

Every answer cites the graph nodes it draws from: the specific control, evidence artifact, or policy. Reviewers verify the source, not the model.

Confidence scoring

Every artifact and every answer carries a confidence score alongside its hash and lineage. Scores are visible, not hidden, so teams know how much weight an output can bear.

Human-in-the-loop routing

Queries that fall below the confidence threshold are routed to human review rather than answered speculatively. The platform prepares; people approve.

The Substrate

The Compliance Graph, explained

The Compliance Graph is the data layer that makes AI-native operation possible. It models compliance as connected entities rather than rows in separate tables: controls, risks, policies, vendors, evidence, frameworks, and AI systems all reference each other. When one entity changes, everything connected to it knows.

Controls

1,400+ controls in a unified catalog

Frameworks

80+ frameworks via SCF crosswalk

Evidence

Each artifact hashed, scored, and lineaged

Risks

Linked to the controls that treat them

Policies

Connected to the controls they mandate

Vendors

Third parties tied to shared controls

AI systems

Governed by 156 AI controls

Vendor relationships and AI systems are first-class entities, which is why vendor risk and AI governance run on the same graph as controls and evidence rather than in bolt-on modules. Terms unfamiliar? The glossary defines each one.

In Practice

What changes operationally

The architectural difference shows up as a workflow difference. Two examples illustrate it. For the signal pipeline itself, see Microsoft-native GRC.

Add a framework without starting over

When a new framework enters scope, the Secure Controls Framework crosswalk with STRM semantic mapping (NIST IR 8477) maps your existing controls to the new requirements. You review the mapping; you do not rebuild the program.

Evidence recalculates on every signal

Signals from Microsoft Defender XDR, Sentinel, Purview, Entra ID, and Azure Policy, plus AWS, Google Cloud, and Oracle Cloud, flow in continuously. Control status reflects the estate as it is now, not as it was at the last assessment.

See the Compliance Graph reason over your estate

Deploy inside your Azure tenant and watch evidence, controls, and frameworks connect from your own signals.

Frequently Asked

Questions, answered

Looking for more? See all frequently asked questions.