5.5 Organizational AI Governance & Evolving Agile Roles

5.5 Organizational AI Governance and Evolving Work

Core principle: Governance should enable beneficial experiments inside clear, enforceable boundaries. It must be based on the actual task, data flow, impact, vendor terms, and evidence—not a product label or a universal checklist.

---

A Usable AI Governance System

An acceptable-use policy can define:

• approved, restricted, and prohibited purposes;
• organization-specific data classes and permitted destinations;
• tool intake, vendor and model change review;
• privacy, security, intellectual-property, accessibility, and environmental criteria;
• human oversight and automation authority by risk;
• evaluation before release and monitoring after release;
• disclosure, logging, retention, deletion, and audit expectations;
• incident reporting, rollback, correction, and appeal;
• owners, exceptions, review cadence, and training.

Do not copy generic tiers and assume every “internal” item is safe for enterprise AI or every “public” item has no obligations. Map the real data and use. Zero Data Retention, single sign-on, tenant isolation, data-loss prevention, and regional processing can be valuable controls when verified, but none is universal or sufficient alone.

Shadow AI and Restrictions

Shadow AI is unapproved AI use outside organizational visibility. Delivery pressure, unavailable approved tools, unclear rules, slow review, or fear of reporting can contribute. A blanket ban may drive some activity underground, but it does not inevitably do so. A ban can be justified for a prohibited, unsafe, or unlawful use.

Reduce shadow risk through clear reasons, usable sanctioned alternatives where appropriate, responsive tool review, training, safe reporting, proportionate monitoring, and consequences that are known in advance. Do not respond with covert employee surveillance that creates a second governance problem.

Give the AI a Job Interview

Scrum.org's curated “Giving your AI a Job Interview” resource offers a useful metaphor: evaluate a tool against the work it will actually perform rather than accepting a polished demo.

Create representative tasks and failure cases. Check source use, accuracy, bias, privacy, security, latency, accessibility, cost, environmental evidence, and integration behavior. Ask the vendor about training use, retention, human access, subprocessors, model changes, incident handling, indemnity, deletion, and portability. Verify answers in contracts and architecture.

Run an adversarial practical test: malicious retrieved instructions, unavailable tools, ambiguous requests, private data, uncommon users, and attempts to exceed permissions. Observe logs and recovery. Define acceptance and stop criteria before the pilot. Re-evaluate after material model or policy changes.

No single criterion is “most critical” for all tools. Copyright indemnity may matter but has scope, exclusions, and conditions. ZDR may matter but not cover every endpoint or customer log. Security certifications are evidence, not guarantees. Model quality without usable governance is insufficient; strong contracts do not make poor outputs valuable.

Environmental Impact

Generative AI can use energy and water in model training, inference, data-center cooling, storage, networking, and hardware manufacturing. Impacts vary by model, hardware, location, energy mix, utilization, prompt and output length, and provider operations. Public estimates are uncertain, so avoid fixed per-prompt claims without current measured evidence.

Teams can:

• choose the smallest fit-for-purpose model or deterministic tool;
• retrieve only relevant context and limit unnecessary output;
• cache and reuse verified results where privacy permits;
• batch work and avoid repeated trial generation;
• measure latency, token or compute use, and provider environmental reporting;
• include energy, water, hardware life, and e-waste in vendor evaluation;
• stop features whose benefit does not justify their impact.

Efficiency can increase use through rebound effects, so inspect total system consumption as well as per-request efficiency. Environmental well-being is part of both OECD and EU trustworthy-AI guidance.

Scrum Accountabilities Do Not Evolve Away

The Product Owner remains accountable for maximizing value and effective Product Backlog management. Developers remain accountable for the Sprint Backlog, quality through the Definition of Done, daily adaptation, and professional accountability. The Scrum Master remains accountable for establishing Scrum and for team effectiveness. AI may change activities and needed skills, not these definitions.

A Product Owner can use AI-supported research but must inspect real evidence. Developers can use generation and agents but must maintain product understanding, quality and recovery. A Scrum Master can prepare facilitation options but cannot delegate team effectiveness to sentiment software.

Cross-Team Learning

An optional community of practice can share approved evaluation cases, incident lessons, source-grounded prompt patterns, environmental measurements, and governance interpretations. It should not become a central task-assigner, prompt police, or new Scrum accountability. Teams working on one product still need one Product Goal, Product Backlog, Product Owner, and a shared Definition of Done under Scrum.

Governance as Empiricism

Make the current policy and approved-tool evidence visible, inspect usage and outcomes, and adapt as technology and law change. Measure product benefit, failures, correction cost, shadow use, incidents, equity, and environmental effect. A governance system succeeds when people can innovate safely, surface problems early, and stop uses whose evidence does not support them.