YarifyStart a conversation

Make unapproved AI use visible without treating everyone as a suspect

Shadow AI governance finds the services, extensions, personal accounts, APIs and workflows that touch company work; then gives staff safe approved routes, proportionate controls and a decision trail. The aim is safer useful work—not an impossible ban on intelligence.

Shadow AI is a governance problem before it is a detection problem

The AI Act does not create one category called “shadow AI.” It creates role- and use-case-specific duties. Article 4 does require providers and deployers to support AI literacy for staff and others operating or using AI on their behalf. The Commission states that this obligation has applied since 2 February 2025.

FactStatus on review dateGovernance consequence
AI literacyBinding Article 4 duty for providers and deployers since 2 February 2025Document context-appropriate education, approved use rules, escalation and training evidence; do not promise a universal competency certificate.
GPAI obligationsApply to GPAI-model providers, with their own role and transition rulesDo not label an ordinary employee or business user a GPAI provider merely for using an external service.
High-risk assessmentDepends on the defined system and intended purposeInventory actual AI-enabled decisions and integrations; route potentially high-risk or prohibited uses to legal and specialist review.
Generative AI governanceNIST AI RMF is voluntary guidanceUse it for an inventory, risk tiering, lifecycle controls and documentation without representing it as law.
MonitoringConstrained by applicable privacy, employment, confidentiality and security obligationsDesign the telemetry and retention model with privacy and employment stakeholders before collecting employee activity.

The Commission timeline and AI literacy guidance are useful official status sources. They do not remove the need to assess the organisation's particular role, country, employment context, data flows and sector rules. Yarify's discovery and control design is an implementation recommendation.

Discover the service, data path and business task

A blocked-domain report cannot tell you whether a user pasted a customer record, connected a cloud drive, called an API through a product, or used an approved enterprise tenant. The NIST AI RMF treats an AI-system inventory as a voluntary governance outcome. A useful inventory identifies enough context to make a proportionate decision.

Browser and network signals

Known AI service domains, application categories, sanctioned-tenant routing, download/upload volume and extension inventory. Avoid assuming a domain proves a risky use.

Identity and SaaS signals

Enterprise SSO, OAuth grants, personal versus managed accounts, API-key ownership, organisation workspaces, connected data sources and administrative audit events.

Engineering signals

Source repositories, dependency manifests, environment variables, outbound APIs, model gateways, agent frameworks, CI/CD integrations and production telemetry.

Business-process signals

Customer support, HR, finance, sales, legal, healthcare, security and development workflows where outputs or inputs could create consequential harm.

Data-classification signals

Public, internal, confidential, personal, special-category, regulated, credential, source-code and trade-secret classifications—without copying the content into the inventory.

People and purpose

Business owner, technical owner, user group, intended task, human-review point, external recipient, country and supplier relationship.

Separate discovery from discipline

Tell people what is observed, why, who can see it, how long it is kept, what will trigger a review and how to contest an incorrect classification. A discovery programme without an approved alternative and a fair review process teaches people to hide useful work more effectively.

Every finding needs one explicit next decision

Do not score a tool “safe” in the abstract. Assess a defined use: the service, tenant, model, feature, data class, task, output recipient, human oversight and decision impact. Then record a decision that staff can understand and systems can enforce.

Approved

A managed tenant, configured settings, permitted data classes, named owner, training and a usable route for employees. Monitor vendor and feature changes.

Approved with controls

A legitimate use that needs tighter data restrictions, human review, contractual terms, a secure gateway, logging, access limitation or a dated remediation plan.

Pause or prohibit

A prohibited, unassessed or unacceptable-risk use; a consumer account handling protected data; or an integration with no feasible ownership or security basis. Give an approved alternative where possible.

Decision inputQuestionEvidence to retain
Role and purposeWho uses the AI capability, for what task, and who receives or acts on the output?Owner, user group, use-case description, process map and human-review point
Data and connectionsWhat enters the service, which tools are connected, and where can outputs go?Data classes, account/tenant, OAuth scope, API route, retention and vendor evidence
ImpactCan the output materially affect a person, customer, security posture, financial result, health, employment or legal position?Risk tier, impact assessment, approver, required controls and review date
Supplier changeCan the model, terms, data handling, training use, geography or features change?Contract, settings, release-monitoring owner, exit route and reapproval trigger

Make the safe path easier than the workaround

A policy without a viable tool, data boundary and support channel merely shifts the risk to personal accounts. The NIST Generative AI Profile is voluntary guidance, but its attention to governance, oversight, documentation and third-party considerations is a practical frame for designing the operating model.

  1. Provide managed access

    Offer an approved tenant or gateway with SSO, contractual controls, administration, defined data settings and support—not a vague list of allowed vendor names.

  2. Publish task-based rules

    Explain what teams may do with public, internal, confidential, personal and regulated data; when output needs review; and which decisions AI must not make or influence.

  3. Train at the point of use

    Satisfy the Article 4 literacy duty through contextual materials, examples, escalation routes and evidence of delivery. Training must match the users, systems and affected people.

  4. Apply proportional controls

    Use browser, SaaS, network, endpoint, identity, DLP, code and API controls according to the risk. Keep policy, detection and enforcement rules versioned and reviewable.

  5. Run an exception route

    Let a team request a use case, data class or integration. Record the decision, controls, expiry and owner; do not force important work into an unmanaged personal account.

  6. Review and retire

    Reassess vendors, new features, models, connected sources, incidents and use cases. Decommission accounts, keys, grants and data routes when the approval ends.

A first delivery should reduce risk and unstick useful work

The output is a working governance loop: discovery signals, a decision register, approved services, control owners, AI-literacy evidence and an escalation path. It should be small enough to run monthly and specific enough to explain a decision in an audit or incident review.

Set the boundary

Agree business objectives, systems, countries, employee and privacy constraints, risk tolerance, data classifications, discovery sources and evidence handling.

Establish the inventory

Collect and reconcile services, tenants, extensions, API keys, integrations and use cases. Mark unknowns, duplicate records and personal-account assumptions.

Triage the highest-risk paths

Review sensitive data, consequential decisions, production integrations, external sharing, unmanaged accounts and high-volume usage with accountable owners.

Launch approved alternatives

Configure one or more managed tools and publish task-based guidance, input restrictions, output-review expectations and support channels.

Implement controls and exceptions

Roll out proportionate discovery and protection controls with transparent notices; create a time-bound, owned process for legitimate exception requests.

Measure and improve

Track managed adoption, unknown services, remediation age, exception expiry, literacy coverage, vendor change and incidents—not a vanity count of blocked prompts.

Shadow AI governance FAQ

What is shadow AI?

Shadow AI is the ungoverned use, acquisition, integration or development of AI capabilities outside an organisation's approved process. It can include a browser-based consumer chatbot, a browser extension, a personal API key, an embedded copilot, a SaaS feature that changes its model behaviour, or an internally built workflow using a third-party model.

Does shadow AI automatically breach the EU AI Act?

No. The applicable legal duties depend on the organisation's role, the system and the use case. However, Article 4 requires providers and deployers to take measures supporting AI literacy for staff and others using AI on their behalf. Other AI Act, data-protection, confidentiality, employment, sectoral and contractual duties may also be relevant. A detection tool cannot determine legal compliance by itself.

Can we monitor employees' AI use by capturing every prompt?

That is rarely a safe default. Start with a defined purpose, necessity and proportionality assessment, privacy and employment-law review, clear notice, minimised telemetry, restricted access, short retention and a route for legitimate use. Prefer service, account, data-classification and policy signals over collecting prompt content unless a reviewed incident requires it.

Are we a GPAI provider if employees use ChatGPT or another model?

Usually not merely because employees use a third-party service. The AI Act has distinct roles; GPAI-model provider obligations apply to providers placing GPAI models on the EU market. An organisation integrating or deploying AI can still have other obligations and risk-management responsibilities. Get legal advice for a specific product, model modification or market role.

What is the first useful deliverable?

A decision-ready inventory: which AI services and integrations are being used, who owns them, what data and business process they touch, their vendor and account model, the risk tier, the approved decision, and the control or remediation owner. It should lead to a small number of safe approved paths, not an unmaintained list of blocked domains.

Primary sources and status

Reviewed 4 September 2026. The AI Act is binding EU law. The Commission's timeline and literacy material explain current application status but do not replace a role- and use-case-specific legal assessment. NIST AI RMF material is voluntary guidance, not a legal standard. Yarify's inventory, telemetry, control and delivery design are implementation recommendations; privacy, employment, data-protection and sectoral obligations require appropriate specialist assessment.

  1. Regulation (EU) 2024/1689 — Artificial Intelligence ActBinding AI Act text, including Article 4 on AI literacy and the roles of providers and deployers.
  2. European Commission — AI Act application timelineOfficial timeline for the Act, AI literacy, GPAI, high-risk systems and other phased provisions.
  3. European Commission — AI talent, skills and literacyArticle 4 applicability, its provider/deployer scope, and the Commission's current explanation of the literacy duty.
  4. NIST AI Risk Management FrameworkVoluntary AI risk-management framework and the Generative AI Profile.
  5. NIST AI RMF CoreVoluntary Govern, Map, Measure and Manage functions, including an inventory outcome for AI systems.

Bring one AI workflow your policy cannot currently explain.

Tell us the business task, service or integration, data types, users, owner, countries and the safe alternative employees actually need. We'll scope discovery and governance that produces a defensible decision without turning into blanket surveillance.