CTO says AI needs a new governance model

Tyrone Grandison has held many C-level roles in his 35-year career in technology, and he is currently the CTO of Cornerstone Assurance Corporation. He's also the author of The AI Revolution and Culture That Lasts.

We spoke with Tyrone to learn how AI is changing governance in technology organizations. Here's what he told us.

35 years in technology

I lead a lean technology organization supporting a growing insurance and financial services business called Cornerstone Assurance Corporation. What makes the role particularly interesting is that we are building a modern technology stack, while operating in an industry with significant regulatory requirements, sensitive financial data, complex carrier integrations, and very little tolerance for getting things wrong.

I started my career as a computer scientist, long before AI became the topic of every boardroom conversation and conference keynote. Over the years, my work took me from building technology to leading organizations through what technology was doing to them. I’ve served as Chief Artificial Intelligence Officer, Chief Technology Officer, Chief Information Officer, and Deputy Chief Data Officer. I’ve worked across government, academia, startups, consulting, nonprofits, and large enterprises.

After 35 years in technology, I’ve had the privilege of watching several things get introduced as “the technology that will change everything.” And some of them actually did.

Every major shift forces leaders to make decisions before they have perfect information. It challenges business models, operating models, culture, talent, governance, and sometimes our understanding of what our own jobs are supposed to be. AI is doing all of that at once.

But what makes this moment particularly fascinating to me is that we’ve moved beyond AI simply helping us analyze information. We now have systems that can generate, reason, plan, create, write code, use tools, and increasingly take action. That fundamentally changes the leadership conversation.

The question used to be, “What can AI do?”

I think that’s quickly becoming the least interesting question. Even the wrong question.

The much more important questions are: What should we allow it to do? Where does human judgment remain essential? How do we redesign organizations when insight itself becomes abundant? And how do we capture the extraordinary upside of this technology without creating risks we don’t understand or systems we can’t govern?

That’s where my work sits today. I work with executives and organizations to help them separate the signal from the considerable amount of noise surrounding AI, understand what is actually changing, and turn that understanding into strategy, governance, products, and measurable business outcomes.

How AI transforms software development lifecycles

One of the biggest changes I made at Cornerstone Assurance Corporation was to redesign our software development lifecycle around the assumption that AI will write a meaningful percentage of our code.

Before that change, we followed a fairly traditional engineering workflow. A developer picked up a requirement, designed the solution, wrote the code, created tests, submitted a pull request, and another engineer reviewed it. We used automation, of course, but humans still performed most of the cognitive work from requirement to deployment.

AI completely changed the economics of that model.

So, we introduced an AI-assisted development pipeline using GitHub Copilot for code generation and refactoring, ChatGPT and Claude for AI-led architectural exploration, requirements decomposition, debugging, and test-case generation, with our normal CI/CD and security tooling providing the deterministic controls around the AI-generated work.

Why AI-generated code requires a new governance model

But the important change was not, “Hey everybody, you have Copilot now.” We changed the governance model.

Approval gates

We now treat AI-generated code almost like code submitted by a very fast junior engineer who never sleeps, has read an absurd amount of documentation, and occasionally says something completely wrong with tremendous confidence.

That means AI can generate code, unit tests, API contracts, documentation, database queries, infrastructure definitions, and proposed fixes, but it cannot approve its own work or have an uncontrolled path to production.

We introduced explicit human approval gates for security-sensitive changes, authentication and authorization, customer and financial data handling, external integrations, and production infrastructure.

Automated testing

We also expanded automated testing and code review because the bottleneck shifted. When AI dramatically increases how quickly you can produce code, your problem stops being code generation. Your problem becomes proving that the code deserves to run.

A simple example is test creation. Previously, an engineer might implement a feature and then write the obvious unit tests. Now we can ask AI to generate adversarial test cases as well. What happens with malformed input? What happens when an API returns an unexpected response? What happens at a permissions boundary? What happens when a customer record contains incomplete data?

That gives the human engineer a different job. Instead of spending all of their time producing artifacts, they spend more time challenging assumptions and validating code behavior.

Governing AI

We also changed how we govern AI itself. We log AI-assisted activity where appropriate, keep sensitive customer information out of consumer AI tools, control which models and services can access enterprise data, and separate experimentation from production access. In insurance and financial services, “the model thought this was a good idea” will never constitute a governance strategy.

How AI shifts the engineering bottleneck

The biggest result I’ve seen from integrating AI into our engineering workflows is speed, but I always add an asterisk to that answer because speed in the wrong direction is not productivity.

AI has dramatically compressed our development cycle. We’re seeing work that previously took a developer several days move from requirement to testable implementation in hours. For prototyping specifically, I would estimate that we’ve reduced cycle time by roughly 50 to 70 percent.

And documentation has probably produced the least glamorous, but most immediate efficiency gain. API documentation, release notes, test documentation, code explanations, and first drafts of technical specifications no longer need to start with a blinking cursor. AI produces the first 70 or 80 percent, and my team spends its time correcting and improving rather than creating everything from zero.

But there’s a downside, and I think technology leaders need to talk about this more: AI makes it incredibly cheap to produce bad code quickly.

We discovered that the limiting factor moves downstream. If I can generate five times as much code, but humans still have to understand, review, test, secure, deploy, observe, and maintain it, I haven’t necessarily increased system throughput. I may have just created a traffic jam at code review.

That has probably been the most valuable lesson for me. I no longer optimize my engineering organization primarily for how quickly we can write software. AI is rapidly commoditizing that part. I optimize for how quickly we can prove that software deserves to run in production. That is a very different engineering organization.

Where AI gets a voice vs. where it gets a vote

I’ve become pretty deliberate about separating two things: where AI gets a voice and where AI gets a vote. At our organization, AI now has a voice in almost every stage of our technology lifecycle. It does not get a vote on every decision.

Some examples:

• Architecture: We use ChatGPT and Claude as architectural sparring partners. If we’re designing a new service, I can give the model our requirements, constraints, existing interfaces, security boundaries, expected transaction volume, and failure scenarios. I’ll have it propose multiple architectures, identify tradeoffs, challenge our assumptions, and even argue against its own recommendation. What I will not do is ask, “What architecture should we use?” and then build whatever comes back. The final architecture decision stays human because architecture involves context that extends well beyond technical optimization. I have to consider our business strategy, regulatory obligations, operational maturity, risk tolerance, cost, technical debt, and what my team can actually support at 2:00 in the morning.
• Code: We give AI considerably more latitude there. We use GitHub Copilot for code generation, refactoring, documentation, and unit-test creation. We also use ChatGPT and Claude to troubleshoot defects, explore implementation approaches, and generate adversarial test cases. AI can write a first implementation incredibly quickly. A human engineer still owns the pull request and approves what ultimately merges.
• Testing: This has probably shifted the furthest toward AI. I love using AI to ask, “How would you break this?” We can find cases that a developer who just spent two days building the feature might unconsciously overlook. AI becomes a very inexpensive, extremely persistent adversary.
• Security: This is where I deliberately reverse the equation. AI helps us identify vulnerabilities, inspect code patterns, model threats, and generate attack scenarios, but as I said, humans retain authority over security acceptance, identity and access decisions, sensitive-data handling, and exceptions. Prompt injection and sensitive-information disclosure remain recognized risks in LLM applications, so connecting AI to enterprise systems requires more controls, not fewer.
• Incident response: This sits somewhere in the middle. AI can ingest logs, correlate events, summarize thousands of lines of telemetry, propose likely root causes, and recommend remediation steps. That can dramatically compress the first 30 minutes of an incident. But if somebody wants to disable a production service, roll back a critical deployment, change a security policy, or take an action that affects customers, a human makes that call.
• Backlog prioritization: I use the same rule here. AI can analyze support issues, engineering effort, dependencies, product usage, and business objectives and say, “Here is how I would prioritize these 40 things and here’s why.” That is incredibly useful. But AI doesn’t understand our strategy better than we do. Product and technology leaders make the final prioritization decision.

So my rule is pretty simple: AI gets more autonomy when the action is reversible, observable, testable, and low consequence. Human authority increases as an action becomes harder to reverse or carries greater customer, financial, security, regulatory, or reputational impact.

A real-world engineering workflow

Here's an example of a “requirement to production with AI in the loop” workflow. Say we need to add a new capability to an agent workflow that pulls customer and policy information, applies a set of business rules, and recommends the appropriate next action:

1. It starts with the requirement. Instead of an engineer receiving a loosely written ticket and immediately coding, we use ChatGPT or Claude to interrogate the requirement. We give it the user story, acceptance criteria, relevant business rules, API contracts, and technical constraints. Then we ask it to identify ambiguity, missing edge cases, dependencies, security concerns, and questions we should answer before anyone writes code. That sounds simple, but it catches a surprising amount of expensive confusion early.
2. Next comes architecture and task decomposition. We use Claude and ChatGPT to explore implementation options and break the requirements into components. The model might identify an API change, a data-model change, an integration dependency, authorization requirements, telemetry, and the necessary test cases. We also ask it to argue against its proposed architecture. A human engineer makes the architectural decision. AI provides options. We own the consequences.
3. Then, we move into implementation. We use GitHub Copilot inside the development environment to generate boilerplate, implement well-defined functions, refactor code, create API clients, explain unfamiliar sections of the codebase, and generate documentation. The engineer moves from typing every line to directing, reviewing, and refining the implementation. That distinction matters. I don't want developers becoming very expensive autocomplete operators. I want them thinking about the system.
4. Then, we give ChatGPT or Claude the requirement and implementation and essentially say, “Great. Now break it.” AI helps generate adversarial scenarios, and Copilot helps turn them into automated unit and integration tests.
5. Then, the deterministic machinery takes over. The pull request enters our CI/CD pipeline. We run automated tests, static analysis, dependency and vulnerability scanning, and our normal quality gates. A human engineer reviews the pull request.
6. Then, we deploy incrementally. The change moves through development and staging before production. Where appropriate, we use feature flags or controlled rollout patterns so we can limit exposure, observe behavior, and roll back quickly.
7. And AI's job still isn't finished. Once the feature runs, AI becomes an observability assistant. We use it to summarize logs, correlate error patterns, analyze unexpected behavior, and help engineers move from “something is wrong” to a plausible root cause much faster.

How to change engineering behavior with AI

I wish I had understood earlier that giving engineers AI tools is easy. Changing engineering behavior is the hard part.

When we first started using tools like GitHub Copilot, ChatGPT, and Claude, I approached the rollout the way many technology leaders do. Give talented engineers powerful tools, establish some sensible guardrails, and wait for productivity to increase.

It did, but not uniformly and not always in the ways I expected.

The first thing I learned was that access does not equal adoption, and adoption does not equal proficiency.

Two engineers can have exactly the same AI tool and get wildly different results. One treats AI like autocomplete and saves a few keystrokes. Another learns how to provide context, decompose problems, challenge outputs, generate tests, explore alternatives, and use the model as a technical sparring partner. The productivity difference between those two people can become enormous.

I would have invested in AI literacy and working patterns much earlier. Not “here is a two-hour prompt engineering class,” but practical examples built around our actual engineering work.

Tyrone Comments

I would have invested in AI literacy and working patterns much earlier. Not “here is a two-hour prompt engineering class,” but practical examples built around our actual engineering work.

How AI is transforming technology leadership

We spend a lot of time asking what AI will do to developers, architects, analysts, and other technical roles. I think CTOs need to turn that question around and point it at ourselves.

For most of my career, technology leadership rewarded knowing things other people didn’t. Experience gave you pattern recognition. Technical expertise gave you authority. You could walk into a room and provide an answer that might have taken someone else days to find.

Now, I can put an incredibly capable AI system in everyone’s hands. That changes leadership.

I no longer think my value as a CTO comes from having the answers. It comes from asking better questions, providing context, making tradeoffs, exercising judgment, and creating an environment where humans and machines make each other better.

That requires humility. AI will sometimes identify an approach I didn’t consider. A junior engineer with great AI skills may challenge an assumption that someone with 25 years of experience considers obvious. I think great technology leaders need to welcome that.

The CTO of the AI era cannot simply be the smartest technical person in the room. We have to become the people who design the room. Who gets a voice? What does AI get to decide? Where does human judgment remain essential? How do we know when we’re wrong?

That’s the leadership transformation.

Why CTOs should be cautious of efficiency gains

My biggest piece of advice to CTOs right now is this: Don’t confuse moving fast with making progress.

There is enormous pressure on technology leaders to “do something with AI.” Boards are asking about it. CEOs are asking about it. Employees are already using it, whether you have a policy or not. Every vendor has suddenly discovered that their product has been “AI-powered” all along.

It is very easy to become reactive. But I think the CTO’s job right now is to create clarity in the middle of that noise.

• First, use the technology yourself. And I mean really use it. Don’t build your AI strategy entirely from analyst reports and vendor demonstrations. I use tools like ChatGPT, Claude, and GitHub Copilot because I need firsthand experience with where they are extraordinary, where they fail, and how quickly those boundaries are moving. You cannot effectively lead a technological transition that you only experience through PowerPoint.
• Second, start with business constraints, not AI capabilities. I’m much less interested in asking, “Where can we use generative AI?” than asking, “Where are we slow, expensive, inconsistent, capacity-constrained, or leaving customers frustrated?” Then I can determine whether AI actually belongs in the solution.
• Third, fix your foundations. AI will not rescue bad data, weak APIs, poor observability, nonexistent documentation, or dysfunctional engineering practices. It will often amplify them. AI acts as an amplifier of the underlying organization and technical system.
• Fourth, design governance around consequences, not fear. I don’t want a 47-page AI policy that effectively says, “Please don’t do anything interesting.” I want controls proportional to risk. Let people experiment aggressively where actions are reversible and low consequence. Increase human oversight as decisions begin affecting customer data, money, security, regulatory obligations, or production systems.
• Fifth, and this may be the most important one, redesign the work instead of simply adding AI to the work. If my development process has twelve steps and AI makes step four 70 percent faster, I haven’t transformed engineering. I have accelerated step four.
• And finally, protect human judgment while aggressively eliminating human drudgery.

I think CTOs have a rare opportunity right now. Don’t just ask how AI makes your current organization more efficient. Ask what organization you would build if you were starting today. That is the more uncomfortable question. It is also the one that will separate the companies that simply use AI from the companies that actually transform because of it.

Follow along

You can follow Tyrone Grandison's work on LinkedIn and his personal website. You can also check out his books, The AI Revolution and Culture That Lasts.

More expert interviews to come on The CTO Club!