AI Governance Lead

Job Purpose

Around 2,200 people at Tungsten Automation now use AI in their daily work, and a growing number of them build with it. Some are professional developers. Many are business users who ship working applications without an engineering background.

The AI Governance Lead owns the governance of what they create: the skills, plugins, and applications used across the company, and the standards and tooling that let them be built once and reused everywhere. Skills are reusable instruction sets that let an AI assistant carry out a defined piece of work to a standard. They are how specialist knowledge gets packaged once and reused. Today they are being written across the company with no shared standard. The purpose of the role is to make AI value creation scale beyond what any single team can hand-deliver.

This is an evolving role. The function is young and priorities will shift over the first year. The person in this role will help decide what they are. Demand already exists and comes from departments with real commitments.

Key Responsibilities

Working close to the business

· Spend real time with people in every department, understand what they are trying to solve, and work alongside them while they build. This is not a queue-based role.

· Understand each department's processes and what they are actually trying to automate.

· Judge when something built for one person should become a shared asset for a team, a department, or the company.

· Surface duplication and consolidate it. Connect people who do not know they need the same thing.

Enablement

· Build and run the onboarding path that takes someone from AI user to capable builder.

· Run training, workshops, and regular office hours for the builder community.

· Grow a community of practice so builders help each other rather than routing everything through a single person.

· Identify and develop the strongest builders in each department into local points of contact.

· Write documentation that reduces the number of questions only one person can answer.

· Support without doing the work for people. The goal is self-sufficiency, not a service desk.

Governance of skills, plugins, and applications

· Own the global catalogue of skills, plugins, connectors, and applications: what exists, who owns it, what version is current, what has been retired.

· Set the authoring standard and define what “ready for internal release” means.

· Review and approve everything before it is published, and re-review when the underlying process changes.

· Run the distribution mechanism so assets reach the right audience, whether company wide, per department, or per team.

· Prevent overlap, and ensure sensitive assets are scoped and reviewed with Security and Privacy.

· Measure what is actually used and retire what is not.

Blueprints and standards

· Define the architectural template internally built applications follow, covering telemetry, logging, security, authentication, and data handling.

· Seed new projects with guardrails and starter repositories so the right thing is the easy thing.

· Evolve the standards as the estate grows.

Platform, source control, and access

· Configure, deploy, and run containerised applications on Azure, including networking, secrets, and scaling. Own monitoring, alerting, and incident response.

· Configure database connections and permissions per application.

· Own repository and organisation governance: permissions, branch protection, secret scanning, dependency policy, CI/CD pipelines, app installations, and service identities.

· Control who has access to what, using OIDC, Entra ID, OAuth scopes, and the correct token model.

· Run security scanning across the estate and act on what it finds.

· Act as the technical interface to IT, and as technical counterpart to InfoSec, Legal, and Privacy

Required Skills

Technical

· Practical Azure experience beyond end user level: container workloads, managed databases, identity, secrets, cost.

· Working knowledge of OAuth 2.0, OIDC, and SSO with Entra ID, including debugging authentication and permission failures.

· Source control platform governance: permissions, branch protection, secret scanning, dependency policy, CI/CD.

· SQL and experience integrating third-party APIs.

Working with people

· Explains technical constraints to non-technical audiences without condescension or oversimplification. You will spend as much time in front of a room as in an editor.

· Builds credibility with people who do not report to you, and gets standards adopted through persuasion rather than mandate.

· Reads an organisation: notices who is solving the same problem twice, and brings them together.

· Coaches toward self-sufficiency. Comfortable letting someone build it slower and worse than you would, because they will own it afterwards.

· Holds a line under pressure. Applies the release criteria consistently, including when the requester is senior and in a hurry.

Operating style

· Works ahead of demand rather than waiting for tickets.

· Comfortable with ambiguity and shifting priorities in a function that is still being defined.

· Writes clearly. Documentation and standards are a primary deliverable, not an afterthought.

Required Experience

· Master's degree in Computer Science, Engineering, Information Systems, Business Analytics, or a related field. Equivalent professional experience considered.

· 7+ years of professional experience, of which at least 5 building and running production software or platforms, including ownership of something other people depended on staying up.

· Has set a standard that people outside their own team had to follow, and got it adopted without formal authority over those people.

· Has taught or coached non-engineers to build something themselves, and can point to what those people went on to produce independently.

· Has declined or deferred a request in order to protect a standard or a delivery commitment, and kept the working relationship intact.

· Has been the first person in a role with no established playbook, and shaped the priorities rather than receiving them.

· Has worked across a function boundary, for example with Security, Legal, or Finance, and can explain a technical constraint to someone who does not share the vocabulary.

· Experience enabling and supporting internal users at scale (preferred).