Where AI is used in Noru, how customer data is handled, how Cortex tools are gated by role, and how AI output is marked so it is never mistaken for a decision.

Summary

AI is used in a fixed set of places, each a proposal that a person accepts, edits, or ignores. No AI surface approves a policy, closes a control, or changes settings.
Cortex is a tool-calling assistant. The model can only read or change what a registered tool exposes, and the tool list is filtered by your role before the model ever sees it.
Customer data is never used to train a model, and every AI call runs under zero data retention at the model layer. Both commitments are in the Terms and the DPA.

Concepts

Term	Meaning
AI surface	One place where Noru calls a model, with its own instructions and bounded input.
Tool	A typed action the model may ask for, with a schema for its input and a required capability. Tools are the only way Cortex touches your data.
AI marking	The status or label that shows a value came from a model rather than a person.

How it works

Where AI is used

Surface	What the model does	What a person does
Cortex chat and the AI Tasks pane	Answers questions from your records and proposes changes through tools	Confirms every write tool before it runs
Policy drafting and generation	Drafts policy and evidence documents; plans edits you request	Reviews the document; applies or discards a staged proposal
Control guidance	Explains a control and suggests control and evidence mappings in the policy editor	Accepts or ignores mappings
Questionnaire answering and review	Suggests answers to a vendor from its public documents; scores a submission	The vendor submits; a reviewer approves, clarifies, or rejects
Vendor context and risk assessment	Extracts vendors from your organization context; finds public security documents; drafts the risk narrative	Sets likelihood and impact; edits the narrative
Privacy enrichment and policy-link detection	Drafts lawful basis, purpose, retention, and transfers; resolves ambiguous policy links in scans	Accepts drafts field by field
Risk generation and treatment suggestions	Proposes organizational risks and one treatment at a time	Reviews risks marked AI inferred; edits treatments
Slack assistant	Answers `@Noru` mentions and `/noru` commands, read-only	Chooses the channel

Every AI call sends only the context the surface needs: the records in scope, your organization context, and your message. Nothing you put into Noru is used to train, fine-tune, or evaluate a model, ours or a provider's. Prompts and outputs exist at the model layer only for as long as it takes to return your result; nothing is stored there afterwards, queued for human review, or retained for training. Noru itself stores what you enter in order to run the platform, under the retention and deletion terms in the DPA. AI inference is the only processing that may leave the EEA, under EU Standard Contractual Clauses.

One Cortex request

Your session is checked for membership in the active organization, and your role is read from Noru's own record of it.
A per-user rate limit applies.
The instructions are assembled: the Cortex instructions (or the AI Tasks instructions when you are editing a policy body), the record on the page you opened the pane from, your organization context, and your frameworks. A plan request for GDPR, ISO 27001, or CIS v8 adds framework-specific planning instructions.
Tools are bound to your organization and filtered by role.
The model answers, calling at most a handful of tools per turn; a longer task needs another message.
Messages are saved only for conversations on the Cortex page.

How roles gate write tools

Every tool is classified as a read or a write. Before the model runs, tools your role cannot use are removed from the set, so a viewer never sees the tools that update a control, policy, risk, or asset, draft or generate a policy, or create a compliance plan. A proposal tool that only stages a policy diff is still a write, because a viewer could not apply it. A tool without an explicit classification is treated as a write, so an omission costs a viewer a read tool rather than granting a write. Write tools ask for confirmation in the chat before they run, and MCP clients use the same tool set under scopes capped by role.

How AI output is marked

Where	Marking
Risks generated by AI	Status AI inferred until you review them
Controls suggested by AI	Status Inferred
Privacy drafts	AI drafts in the inbox; the record keeps the accepted draft for audit
Vendor documents found by AI	Evidence source AI-gathered
Policy edits from Cortex	A Policy change proposal card; nothing changes until Apply in the editor
Vendor risk narrative and questionnaire scores	Written to the record and dated as an AI assessment

The last row is the only case where AI text lands directly on a record; it is dated and editable, and the decision that matters is still yours.

What AI cannot do

Cortex and the other surfaces cannot approve a policy, delete records, change settings, invite members, connect data sources, or browse the internet. Cortex remembers nothing outside the saved conversation and your organization context. Questionnaire AI cannot verify that an answer is true, and the scanner's AI step never judges compliance.

Cortex quotes your data, but it is a model. Check a status or a quoted policy line against the record before acting on it, and never treat a generated compliance plan as an audit opinion.

Edge cases and failure modes

A model outage fails the surface, not the record. A failed call leaves the record as it was; Cortex says the tool failed in the answer.
Page context is one record. On a policy, risk, or control page the pane sees that record; elsewhere it sees the page or the organization as a whole.
Interrupted answers drop unfinished tool calls. Stopping mid-answer never leaves a half-applied write.

What you can influence

Your organization context under Settings, which is part of every conversation.
Member roles, which decide who sees write tools.
Whether you accept, edit, or discard each proposal.

AI and Cortex