Discovery operations
Discovery helps identify AI that may not yet be registered. It produces signals requiring human review, not automatic declarations that a person or team is using an unauthorised system.
Operating model
Section titled “Operating model”| Stage | Question |
|---|---|
| Coverage | Which business areas, identities, cloud services, repositories or imports are observed? |
| Detection | Which built-in or approved custom rules interpret the signals? |
| Candidate review | Is the signal a real AI system, duplicate, permitted tool or false positive? |
| Reconciliation | Does it match an existing system, supplier, model or prior candidate? |
| Governance action | Should it be promoted, linked, dismissed, monitored or escalated? |
| Assurance | Can coverage, decisions and unresolved gaps be explained to management or audit? |
Sources and credentials
Section titled “Sources and credentials”Define the source owner, purpose, scope, cadence and lawful basis before collection. Use the smallest read scope that can produce the required signal. Store connection credentials through the approved tenant-scoped integration mechanism; do not paste credentials into candidate notes or imports.
Test a source before relying on its coverage. A healthy connection does not prove full coverage if important accounts, regions, repositories or environments are excluded.
Rules and scans
Section titled “Rules and scans”Built-in and custom rules normalise raw indicators into reviewable candidates. Document what a rule detects, expected false positives, risk labels and the owner who can change it. Preview an import or rule change before a live scan where that option is available.
Monitor last run, next run, errors, volume and unusual changes. A sudden zero may indicate a clean environment, but it can also indicate failed collection. A sudden spike may reflect a deployment, rule change or duplicate ingestion.
Candidate and alert decisions
Section titled “Candidate and alert decisions”For each candidate:
- Inspect source, detector, confidence, rationale and supporting artifacts.
- Search for an existing system or related candidate.
- Confirm owner and intended use with an accountable person.
- Promote a real system into the Registry or link it to the matching record.
- Dismiss a false positive with a reason that another reviewer can understand.
- Escalate material unknown use, prohibited tools or sensitive-data exposure.
Alerts should have a named disposition and owner. Bulk actions are appropriate only when the same decision basis genuinely applies to every selected item.
Reconciliation and playbooks
Section titled “Reconciliation and playbooks”Reconciliation prevents duplicate inventory and preserves the chain from raw artifact to governed record. Suggested matches assist review but do not replace confirmation. Discovery playbooks can create or link follow-up risks and evidence work; confirm the target system and workspace before execution.
Assurance reporting
Section titled “Assurance reporting”A defensible Discovery report explains sources, coverage, run health, rule set, candidates, decisions, unresolved artifacts, overdue alerts and limitations. It must not imply that “no candidates” means “no shadow AI” unless coverage and detector effectiveness support that conclusion.
Review checklist
Section titled “Review checklist”- Sources have owners, purpose, scope and review dates.
- Credentials use least privilege and are not exposed in records.
- Rules are tested and false-positive assumptions documented.
- Failed and overdue scans are investigated.
- Candidates have attributable decisions.
- Promotions enter normal intake and routing.
- Unresolved artifacts and coverage gaps are reported.