Noru

AI governance · EU AI Act and ISO 42001

An AI register built from your code, not a policy you filed.

Every model call, agent and eval found in your repositories and recorded as a system — with the EU AI Act's claims about it, one finding per article, each one waiting on a person before it counts. ISO 42001 and the Act run on the controls your security program already has.

Book a demoExplore the platform

The way this usually goes

The AI inventory is a spreadsheet somebody filled in once, and the models it lists are two releases behind the ones in production.

The EU AI Act is read as one deadline, when it is several — Article 5 and Article 50 already apply while the high-risk chapter was deferred.

Enterprise buyers and regulators ask how you govern AI, and 'we take it seriously' doesn't survive the question.

From repository to register

An AI register that assembles itself from your code.

The systems that need governing are the ones your engineers are shipping this week, and the only place that list is accurate is the code. Noru reads it there: an open-source piece finds every model call, agent, prompt and eval in the repository, and the register is built from what it finds — versioned on every push, with a person's name on every claim.

01 · Scan

Found in the repository

The ai-inventory piece reads the repo for model calls, agents, prompts and evals, and names the file and line each one lives on.

02 · Push

Landed from CI

The manifest is pushed with its checksum. An unchanged manifest is a no-op; a changed one is a new immutable version, stamped with the commit that produced it.

03 · Classify

One row per legal claim

Each system gets a classification — purpose, provider, deployment, autonomy, oversight — and one finding for every claim the Act makes about it: Article 5, Article 50, its role and its risk tier.

04 · Review

Accepted by a person

Every claim arrives as a suggestion. Someone with a name accepts, dismisses or reaffirms it, with an expiry and a rationale, and the register records who.

05 · Watch

Drift and expiry, on every run

A re-scan that contradicts an accepted claim, a classification past its expiry, a missing Article 50 disclosure — each opens a finding rather than silently rewriting the record.

The next push diffs against what Noru already holds and lands only what changed

Described where it is built

One manifest, next to the model call.

One entry per AI system, next to the code that calls the model: what it is for, which provider and models, how it is deployed, how autonomous it is, and where a person stands in the loop. Every line cites the file it was read from, and every interpretation carries an owner, a date and an expiry — so the register can tell a live claim from a stale one.

  • Immutable manifest versions, each stamped with the commit that produced it
  • Deployment, autonomy and oversight recorded as typed values, not prose
  • Evals declared with whether they gate CI — an eval nobody gates on is documentation
Browse the pieces on GitHub

One entry per AI system, written next to the code that calls the model: what it is for, which provider and models, how it is deployed, how autonomous it is, and where a person stands in the loop — every line citing the file it was read from.

systems:  - key: support_agent    name: Support agent    purpose: Drafts replies to inbound tickets for an agent to send    provider: anthropic    models: [claude-sonnet-5]    deployment: hosted_api    autonomy: supervised    human_oversight:      - type: human_approval_gate        description: Every draft is sent by a person        refs: [src/support/agent.ts:41]    inputs:      data_categories: [user.contact.email, user.name]      sources: [zendesk]    retrieval:      - name: help_center        kind: document_store    evals:      ci_gated: true      suites:        - name: tone-and-policy          path: evals/support.eval.ts    interpretation:      owner: ml-lead      decided_at: 2026-08-12      expires_at: 2027-02-12      rationale: Assistive drafting; a person sends every replyproviders:  - key: anthropic    vendor_name: Anthropic    dpa_reference: DPA-2026-014
AI register/Claims
3 need review

Every claim waits on a person

Nothing is classified until you say so.

A scanner can find that a chatbot talks to people; it cannot decide whether the disclosure is good enough, or whether a screening tool is high-risk. So nothing in the register is classified until someone with a name accepts it. Each claim lands as a suggestion with the article it comes from and the evidence behind it; your team accepts, dismisses or reaffirms it, with an expiry and a rationale, and the register records who.

  • Article 6(3) not-high-risk determinations are a person's call, recorded with the ground and the profiling gate
  • A re-scan that contradicts an accepted claim opens a drift finding instead of overwriting it
  • Noru's own AI never trains on your data, and every model call runs under zero data retention

EU AI Act, as findings

The Act, one row per legal claim.

The Act is not one obligation; it is a handful of separate ones with separate dates. Article 5 has applied since February 2025. Article 50 transparency applied in August 2026. The high-risk chapter was deferred. Noru records each one as its own finding on each system — with the determination the product can make, the date it binds, and who has to act on it — so the register can say which of your systems has a live obligation today and which has one in 2027.

One finding per legal claim, per system

Each row carries its article, its owner, its expiry and the date it binds

  • Article 5

    Prohibited practices

    In force since 2 Feb 2025

    Eight named practices, screened on every scan

    • Determination: indicated, needs legal review, or no indication
    • Raised on every run, not once at onboarding
    • New practices join the list on 2 Dec 2026

  • Article 50

    Transparency

    In force since 2 Aug 2026

    Chatbots, synthetic content, emotion recognition, deep fakes

    • Disclosure state: present, unclear or absent
    • Absent only after the templates were actually searched
    • Marking grace for existing generative systems ends 2 Dec 2026

  • Article 6 · Annex III

    Role and risk tier

    Deferred to 2 Dec 2027 (Annex III) and 2 Aug 2028 (Annex I)

    Provider, deployer, importer or distributor of the system

    • Tier: high-risk under Annex III or Annex I, not high-risk, GPAI, GPAI with systemic risk, or undetermined
    • Article 6(3) not-high-risk grounds recorded, with the profiling gate
    • Each claim carries its own enforceable-from date

  • ISO/IEC 42001

    Standards alignment

    Voluntary — no statutory date

    Where a system asserts a management-system control

    • ISO 42001 clauses cited per system, mapped to the control library
    • NIST AI RMF recorded as a claim the manifest makes, not a framework Noru runs
    • Evidence lands in the same vault as ISO 27001 and SOC 2

  1. 2 Feb 2025

    In force

    Article 5 prohibited practices apply

  2. 2 Aug 2026

    In force

    Article 50 transparency, enforcement powers and GPAI penalties

  3. 2 Dec 2026

    Next up

    Marking grace ends for generative systems already on the market; new prohibited practices

  4. 2 Feb 2027

    Next up

    Watermark detection interoperability for Code of Practice signatories

  5. 2 Dec 2027

    Deferred

    High-risk obligations for standalone Annex III systems

  6. 2 Aug 2028

    Deferred

    High-risk obligations for AI embedded in Annex I regulated products

Coverage

ISO 42001 and the EU AI Act, on the controls you already run.

Both ship as frameworks in the same control library as ISO 27001 and SOC 2. The EU AI Act's requirements are harmonised onto the controls you already run, so the evidence your security program collects counts for the Act too, and only the AI-specific work is new.

  • ISO 42001ISO 42001
  • EU AI ActEU AI Act

Generated for the EU AI Act

The policy set, drafted against your program

Adding the Act generates the documents it expects, mapped to the controls and evidence that satisfy them — drafts for your team to own, not templates to fill in.

  • AI System Governance & Ethics Policy
  • AI Risk & Impact Assessment Procedure
  • AI Technical Documentation & Transparency Standard
  • AI Test, Evaluation, Validation & Verification (TEVV) Plan
  • AI Data Governance & Management Policy
  • AI Awareness & Competency Framework
  • AI Internal Audit & Assessment Framework

Reconciled to the vendor and the asset

A system, its provider, its oversight: one record.

A model provider is a vendor, and a model call runs on something. Each system in the register resolves its provider to the vendor record — with the DPA and the sub-processor line that go with it — and its runtime to the asset your cloud sync already discovered. The oversight points the manifest declared sit on the same record, including the one that says none, because that is the line an auditor is looking for.

  • Provider resolved to the vendor register; no second list of AI suppliers
  • Runtime resolved to the asset register from the same cloud sync
  • Oversight, evals and data categories as typed fields, with the file and line they came from
AI register/support_agent

Who it's for

One system, every stakeholder

ML & engineering

A manifest next to the code that calls the model, pushed from CI — governance that reads the repository instead of asking you to describe it.

Security & CISO

Every AI provider resolved to a vendor record and every runtime to an asset, so model exposure sits next to the rest of your posture.

Compliance & legal

Article 5, Article 50 and the risk tier recorded per system with the date each one binds — the answer ready before a customer or regulator asks.

Leadership

A register that says which systems carry a live obligation today, and which carry one in 2027 — defensible to a buyer and to a supervisor.

What's included

Platform modules working together

This solution runs on the same system of record as everything else — add modules later without re-platforming.

Controls

Implement once, satisfy many

One control library, mapped across ISO 27001, SOC 2, GDPR and 30+ frameworks — the same evidence reused everywhere.

Risk Register

Know your risk before anyone asks

A live register linked to security findings, controls and treatments — not a yearly workshop artifact.

Policies

Keep every policy acknowledged

AI-assisted drafting, versioning, approvals and acknowledgements, mapped to the controls they satisfy.

Privacy Automation

Map every data flow, continuously

Data maps, records of processing and impact assessments derived from the systems that hold the data and enriched by AI.

Works with

  • AWS
  • GCP
  • Databricks
  • GitHub
  • Microsoft
  • more

Book a demo

See it on your own data.

A walkthrough against your own repositories and the systems in them, with your questions answered by practitioners.

  • 45 minutes, tailored to the frameworks and use cases you care about
  • Answers from practitioners, not a sales script
  • Leave with a concrete rollout plan — or a clear no-fit

We respond within one business day. No mailing lists, no spam.

FAQ

Frequently asked questions

What ML, security and legal teams ask before they put the register in front of a buyer or a regulator.

Talk to us

Which AI frameworks does Noru support?

The EU AI Act (Regulation (EU) 2024/1689) and ISO/IEC 42001, both as frameworks in the same control library as ISO 27001, SOC 2 and GDPR, so the evidence your security program already collects counts for them. A system can also cite NIST AI RMF alignment in its manifest; that is recorded as a claim on the system, not run as a separate framework.

We're an AI company, not a typical SaaS. Does this fit?

That's exactly who it's for. The register is built from your repositories: an open-source piece finds model calls, agents, prompts and evals with their file and line, and the manifest it writes is pushed from CI. Each system resolves its provider to a vendor record and its runtime to an asset, so what you ship is governed as it is actually built and run.

How does Noru handle the EU AI Act?

As findings, not a checkbox. For every AI system the register records one finding per legal claim: Article 5 prohibited practices, Article 50 transparency with the disclosure state, the system's role and risk tier under Article 6 and Annex III, and any standards alignment it asserts. Each carries the article, the date it becomes enforceable, an owner and an expiry, and none of it counts until a person accepts it. The Act's requirements are harmonised onto the shared control library, and adding it generates the policy set it expects.

Can it govern our use of AI as well as our AI products?

Yes. The same framework covers AI you build and AI you adopt — including, transparently, the AI inside Noru itself. For that entry in your own AI register: Noru never uses customer data to train, fine-tune or evaluate a model, and every model call runs under zero data retention terms, so there is no provider-side copy of your prompts to account for. Both are contractual in our Terms and DPA, which is the evidence your ISO 42001 supplier control actually wants.

Related solutions

Privacy · Data protection at scale

Privacy Automation

Learn more

Risk · A live register, and a number

Risk Management

Learn more