AI automation for CTOs: the automation already running

The question a CTO is usually asked is what the company should automate. The more useful first question is what it already has automated, because in any organisation past a certain size the answer is a surprising amount — built by people outside engineering, holding real credentials, running on somebody's account, and invisible.

That is not a problem to stamp out. It is demand that found its own supply, and the response that works is to make a governed route faster than the ungoverned one rather than to prohibit what people are already doing.

What we'll cover

• What is already running
• Why people built it themselves
• Finding it without a witch hunt
• Building it with CodeWords
• What actually needs governing
• Build, buy, or let them build
• The credentials question
• What this costs if ignored
• Answering the question the board is asking
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What is already running

Spreadsheet macros doing things nobody has read in years.

Scheduled scripts on an individual's machine or cloud account.

Automation platform workflows built by operations, marketing or finance.

Integrations connected with personal credentials, which persist after the person leaves.

Browser extensions with broad access, installed by individuals to solve a real problem.

None of it is documented, which is the common property and the actual risk.

Why people built it themselves

The request queue was too slow, which is the honest reason in most organisations.

The need was small and did not justify a project, which is a correct assessment.

Tooling made it possible, and it will continue to become easier rather than harder.

They were solving a real problem, competently, with what they had.

Prohibition does not work, because the underlying pressure does not go away and the response is concealment rather than compliance.

Treat the volume as a measurement of how well the official route is serving people.

Finding it without a witch hunt

Ask, and say why. An amnesty framed as inventory rather than enforcement surfaces most of it.

Look at integration and API credentials issued to individuals, which is where the technical trail is.

Check the automation platforms — most organisations have at least one with accounts nobody tracks.

Look for scheduled jobs in cloud accounts outside the engineering ones.

Watch for the shared personal login, which is both the largest risk and the easiest to find once you look.

Publish what you found, without attribution, since the scale is the argument for doing something about it.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the process, the systems it touches, and what needs approval.
3. Authorize the connections with service credentials scoped to what the automation needs.
4. Describe the exceptions: a failure, a missing approval, an unexpected volume, a system unavailable.
5. Run it in a non-production context first and check the audit trail before pointing it anywhere that matters.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What actually needs governing

Not everything, and trying to govern everything is how a governance programme fails.

Anything touching customer data, which carries obligations regardless of who built it.

Anything writing to production systems, as opposed to reading from them.

Anything holding credentials beyond one person's own access.

Anything a process now depends on, which is the definition that catches the important cases regardless of who built it.

Anything moving money or affecting a financial record.

Leave the rest alone. A marketing automation that formats a report for one person needs no governance and imposing it teaches people to hide things.

Build, buy, or let them build

Buy for the commodity, since a well-served category rarely repays building.

Build where it is your differentiator, which is a smaller set than most engineering organisations assume.

Let them build with guard rails for the long tail, which is the option most organisations do not consider and which is where most of the volume is.

Provide the paved road: approved tooling, service credentials, logging and a review path, so building it properly is easier than building it in the shadows.

Reserve engineering for what needs engineering, which is the real scarcity.

Revisit annually, since categories commoditise and a build decision from three years ago may now be maintenance for no advantage.

The credentials question

Personal credentials are the core problem, technically and operationally.

They break when the person leaves, which is how a finance process fails at month end six weeks after a departure.

They grant more than the automation needs, since a person's access is broader than a task's.

Nothing is auditable — the logs show a person did something they did not do.

Issue service credentials, scoped narrowly, as the primary thing a governed route offers.

Make it the incentive. Credentials that survive a departure are a reason to register an automation rather than a rule requiring it.

What this costs if ignored

Single points of failure attached to individuals rather than to systems.

Compliance gaps where regulated data is processed by something nobody assessed.

Silent failures that nobody is alerted to, discovered when a number looks wrong.

Duplicate effort, with three teams solving one problem separately.

Loss on departure, where a leaver takes the knowledge and the automation stops.

Surprise dependencies discovered during an incident, which is the most expensive way to find out.

Answering the question the board is asking

A CTO is increasingly asked what the company is doing about AI automation, which is a different question from what the engineering organisation is doing, and answering it badly commits you to work nobody wanted.

Separate the two claims. Automating existing processes and changing what the product does are different programmes with different risks, and they get conflated in the same conversation.

Report what is already deployed, which is usually more than the board assumes and reframes the discussion from starting to governing.

Name the constraint honestly. It is rarely the technology and usually data quality, process clarity or the capacity to maintain what gets built.

Quantify the maintenance, since every automation is a permanent commitment and a board approving twelve of them has approved an ongoing cost nobody stated.

Resist the headcount claim unless you believe it, because it is the promise most often made and most rarely delivered, and it is the one you will be held to.

Give them a measure — automations in production, their owners, what they touch, what they cost — so the next conversation is about a number rather than an impression.

Making it survive

Maintain an inventory with an owner per entry, reviewed rather than written once.

Require a review date for anything registered, so the list reflects reality.

Alert on the automation failing, which is the thing individually built automation never has.

Include automation in offboarding, since the leaver checklist is where ownership transfer should be forced.

Report the inventory to leadership periodically: what exists, what it touches, and what is unowned.

Limits worth knowing about

You will not find all of it, and an inventory is a moving target rather than a completed project.

Governance has a cost and over-applying it pushes activity back underground.

Approved tooling is not always better, and imposing something worse than what people found themselves guarantees non-compliance.

Engineering capacity is the constraint, which is why absorbing the long tail into the engineering queue is not the answer.

Culture determines the outcome. If people are punished for what is found, the next inventory will be empty and wrong.

What to build first

The inventory, gathered by asking with an explicit amnesty. It changes nothing technically and it converts an unknown into a list — and in most organisations the list is both larger than expected and contains at least one thing a critical process depends on that nobody in engineering knew existed.

Two habits make the difference. Offer service credentials as the primary benefit of registering an automation, since credentials that survive a departure are an incentive rather than a rule and they solve the largest technical problem at the same time. And govern by what an automation touches rather than by who built it, because governing everything pushes the activity back into the shadows and losing visibility costs more than the governance was worth.

Frequently asked questions

What is the first thing a CTO should do about automation?

Find out what is already running. In most organisations there is substantially more than engineering knows about, built by people outside it, holding real credentials, and undocumented.

Why do people build automation outside engineering?

Because the request queue is slow, the need was too small to justify a project, and the tooling made it possible. All three are correct assessments rather than misbehaviour.

How do I find shadow automation?

Ask with an explicit amnesty, look at integration credentials issued to individuals, check the automation platforms, look for scheduled jobs in non-engineering cloud accounts, and find the shared personal logins.

What should actually be governed?

Anything touching customer data, writing to production, holding credentials beyond one person's own access, moving money, or that a process now depends on. Governing everything pushes activity back underground.

What is the core technical problem?

Personal credentials. They break when the person leaves, grant more than the task needs, and make the audit trail wrong — the logs show somebody did something they did not do.

How do I make people register their automations?

Offer service credentials that survive a departure. It is an incentive rather than a rule, and it solves the largest technical problem at the same time.

Should everything be absorbed into the engineering queue?

No. Engineering capacity is the constraint, which is exactly why the long tail should be built by the people who need it, on a paved road with guard rails, rather than queued.

What does ignoring this cost?

Single points of failure attached to individuals, compliance gaps, silent failures found when a number looks wrong, duplicated effort, and dependencies discovered during an incident — which is the most expensive way to learn about them.

How should a CTO answer "what are we doing about AI automation"?

By separating automating existing processes from changing the product, reporting what is already deployed, naming the real constraint — usually data quality or maintenance capacity rather than technology — and quantifying the ongoing commitment each automation represents.

Should automation be justified by headcount reduction?

Only if you believe it. It is the claim most often made, most rarely delivered, and the one you will be held to at the next budget round.

Related reading

• Workflow automation for DevOps
• Automating security vulnerability scanning
• Workflow automation for RevOps teams