TrackerHelp

Common use cases

Four scenarios that cover most of how teams actually use Tracker. Pick the one closest to your situation; the steps assume you've done Getting started already.

1. Get EU AI Act ready before your high-risk system goes live

Most common use case for Tracker. You're shipping an AI product into the EU, you've concluded it's high-risk under Article 6, and you need a defensible compliance posture before deployment (Article 6 hits August 2026; some prohibitions are already in force).

  1. Create one project per AI system in scope. Don't lump multiple systems together — each system gets its own conformity assessment.
  2. Import the EU AI Act framework pack. Articles 9 (risk management), 10 (data governance), 11 (technical documentation), 12 (logging), 13 (transparency), 14 (human oversight), 15 (accuracy / robustness / cybersecurity), 16 (provider obligations), 17 (QMS), 26 (deployer obligations) and 50 (transparency for certain systems) all land as ready-to-track controls.
  3. Walk top-to-bottom. For each requirement: capture what you already have as evidence (PR URL, doc link, audit-log export); log a gap where you don't; spin gaps into tasks with a target date.
  4. Layer the NIST AI RMF and OWASP LLM Top 10packs alongside if your system is generative — they cover the operational and security territory the AI Act gestures at but doesn't prescribe.
  5. Use the project dashboard to track Article-by-Article completion. A fresh import of the EU AI Act pack is ~30 requirements; a focused team closes the major gaps in 4–8 weeks.

What this gets you: a structured record of how each Article is satisfied, with evidence linked to actual changes, and a gap register for everything outstanding. That record is what you hand to a notified body or your legal counsel when conformity assessment time comes.

2. Stack ISO 42001 alongside SOC 2 for enterprise procurement

You're selling AI to enterprise. Their procurement asks for SOC 2 (security posture) and increasingly for ISO 42001 (AI management system). Both need a paper trail; you don't want two parallel tracking systems.

  1. Import the ISO 42001 pack. Clauses 4–10 (the management-system shell) plus the Annex A controls land directly as project requirements.
  2. Use a separate platform (Vanta, Drata, Secureframe — whatever procurement recognises) for SOC 2 itself. Tracker complements rather than replaces the SOC-2 layer.
  3. Where a control overlaps — risk management, access control, data governance, incident response — treat the SOC 2 evidence as also satisfying the ISO 42001 requirement. Add the SOC 2 audit reference as evidence on the ISO 42001 requirement; the audit log captures the cross-link.
  4. Layer ISO/IEC 23894 (AI risk management process — the operational counterpart to 42001) if you need depth on the risk-management clauses.

What this gets you: one compliance surface that satisfies both audits, with explicit cross-references where a single piece of evidence covers multiple frameworks.

3. Put compliance in the AI agent's context with Claude Code

If your team uses Claude Code (or any MCP-aware agent), evidence logging becomes part of the work itself — the agent sees which requirements your edits affect and can log evidence inline, without anyone having to come back to it later.

  1. Wire the MCP per Claude Code + MCP. Mint a token, set .env, run claude mcp add tracker.
  2. Drop docs/claude/skills/tracker-consult.md (in this repo) into your consuming project's .claude/skills/. It teaches the model the consult-before-edit ritual.
  3. When the agent starts a session, it auto-reads three resources: your active requirements, your open gaps, and the path-map (which file globs are load-bearing for which requirements).
  4. Before any non-trivial edit, the agent calls check_changewith the paths it's about to touch. The response tells it which requirements are affected, surfaces any open critical gaps, and suggests evidence to capture.
  5. After the change ships, the agent (or you) calls add_evidence with the PR URL and the touched paths in filePaths. Future check_change calls now know those paths map to that requirement — the path map sharpens with each evidence-tagged change.

What this gets you: compliance evidence accrues as a byproduct of normal development, not as catch-up work the week before an audit. The audit log on your org records every consultation (mcp.context.read, mcp.check_change.called) so you can prove the agent was informed before each change.

4. Prepare an audit-ready evidence package for a customer or auditor

A customer asks “show me your AI governance posture” or an auditor schedules a review. You need to produce a coherent package fast, without scrambling.

  1. Pick the project (or projects) in scope. Make sure each requirement has either evidence or a gap with a target date — incomplete records read worse than honest gaps.
  2. Use the CSV export on requirements / gaps / tasks pages to get a snapshot the auditor can ingest into their own tooling. Each row carries status, owner, dates, and the evidence-count column.
  3. Walk the auditor through the project dashboard live. Framework completion percentages, gap severity breakdown, and the recent activity timeline are all visible at a glance.
  4. Show the audit log (Organizations & teams covers permissions). Append-only at the database layer with IP/user-agent on each event — the kind of immutability auditors ask for and rarely get from spreadsheet-based systems.
  5. For each gap they probe, surface the linked tasks and target dates. A gap with a named owner and a reasonable plan beats a requirement marked “met” with no evidence.

What this gets you:a credible narrative of where you are, where you're going, and how you got there — backed by an immutable record. PDF compliance-package export is queued for a future release; until then the CSV exports plus a screen-share cover the same ground.

Next