Ardent Tools: A 90-Day Governance Rollout After a Public Gen AI Failure

Objective for 30 days: a defensible inventory, an agreed risk tiering and a scoped first release - not a completed policy.

Activities:

1. Sponsor and decision rights. Confirm who can lift the freeze and who owns AI risk. Without that, everything else is advisory. Recommend a small AI governance council chaired by the CRO with CIO, CISO, legal and a business representative.
2. Reconcile shadow AI from evidence, not interviews. Pull procurement contracts, cloud and API spend, SSO/OAuth grants and expense claims to find tools nobody declared. Cross-check the six vendor contracts against the 12 known pilots.
3. Structured interviews with each pilot owner: purpose, data, model source, human review, failure modes, customers affected.
4. Risk triage workshop using factors already agreed in principle - customer-facing output, autonomy, regulated data, EU staff impact, reversibility. Place all 12 pilots in tiers.
5. Baseline the process, not just the tools. Measure current time from request to production for the last five deployments. That becomes the metric the 'governance is a tax' argument must beat.
6. Pick two lighthouse use cases - the RFQ tool (to fix a known failure) and the maintenance assistant (high value, lower risk).

Artefacts: AI use-case and model inventory; risk tiering with rationale; contract gap list; incident reconstruction of the RFQ failure with root cause; draft minimum control set; baseline cycle-time metric.

Defer: full policy prose, enterprise-wide tooling rollout, and retrospective validation of all 12 pilots. Doing these first would consume the 90 days and produce no visible risk reduction.

Days 1-30 - see the estate. Inventory, risk tiering, RFQ root cause, freeze-exit criteria drafted, council formed, baseline cycle time measured.

Days 31-60 - fix the failure and prove the pattern.

• Remediate the RFQ tool: retrieval grounding against approved pricing and lead-time sources, no free-text commitment to customers without human send, evaluation set built from the actual failure, logging in place. Re-release through the new approval path.
• Stand up factsheets for all 12 use cases and monitoring for the three production tools.
• Publish the minimum control set: intake form, tier-based requirements, human-oversight standard, incident route, vendor documentation requirements.
• Consult the works council on any tool affecting staff, starting now - it is a long-lead item, not a day-85 activity.

Days 61-90 - make it repeatable and lift the freeze.

• Run two new use cases end to end through intake to approval, to prove the path is usable.
• Retire or contract-remediate the two unknown vendor tools.
• Define EU handling for the Czech plant: residency of logs, staff-impact assessment, consultation record.
• Measure cycle time again against the baseline.

What must be true at day 90: every production AI system has an owner, a tier, a factsheet and logging; the RFQ failure has a documented fix; the freeze has clear, written exit criteria that legal and the CRO have signed.

What to show the board: not a policy deck. Show the inventory with tiers, the RFQ failure and its remediation evidence, two use cases approved through the new path, and the cycle-time comparison before and after. Say plainly what is still missing.

Do not argue culture; change the transaction cost. The objection is usually rational: the current approval route is slow, opaque and unpredictable, so governance looks like delay with no benefit.

Tactics that work:

1. Publish the rules before enforcing them. A tier-based control set tells a team in advance what a Tier 2 customer-facing assistant needs. Unpredictability, not requirement, is what teams resist.
2. Ship pre-approved patterns. An approved RAG architecture with guardrails, logging and evaluation harness means the maintenance assistant's successor starts from a known-good template rather than a blank page.
3. Make the fast path real. Low-risk internal tools should clear intake in days with minimal evidence. If everything is treated as Tier 1, the objection becomes true.
4. Measure and publish cycle time. Use the pre-governance baseline from discovery. If the new path is slower, fix the path rather than blaming the teams.
5. Give engineering a seat and a stake. Let engineering co-design the controls and own the evaluation harness; governance that engineers build is governance they defend.
6. Connect it to their actual pain. The RFQ incident froze every team's roadmap. A predictable path is what unfreezes delivery - that argument lands with engineering leads far better than risk language.
7. Use the incident honestly. Do not moralise about the fabricated lead time; analyse it as a missing grounding and human-send control, and fix it visibly.

What not to concede: the freeze exit criteria, logging, and human send-off for customer commitments. Those are non-negotiable. Offer flexibility on how they are implemented and on the evidence format, not on whether they exist. Track adoption through the number of teams using the fast path voluntarily - if nobody uses it, the design is wrong, not the culture.