Fractional CTO for SMB teams adopting AI

An engineering manager can own delivery and still leave a company exposed on AI. Delivery answers whether work ships on time and runs reliably. AI risk ownership answers who may send which data to a model, what an agent may change without approval, how the company reverses a bad action, and how much the system may spend before it stops.

For most small and midsize businesses, those decisions do not justify a full-time executive. They do require one named technical owner with authority across engineering, security, finance, legal, and operations. A fractional CTO is often the right shape when the engineering manager lacks that cross-company mandate or the experience to write the rules. The title matters less than the decision rights, but leaving the role implicit is a mistake.

Delivery ownership stops at the model boundary

An engineering manager should remain accountable for delivery, but delivery authority does not automatically cover enterprise AI risk. The manager can choose how the team estimates work, reviews code, deploys releases, and responds to ordinary defects. Once a model receives customer data, acts through a production credential, or creates variable third-party cost, the decision crosses several company boundaries.

Consider a coding agent connected to a source repository. At first glance, this looks like another developer tool. In practice, someone must decide whether the agent may read private repositories, issue tracker comments, support transcripts, environment files, and production logs. Someone must also decide whether it may open a pull request, merge it, run database migrations, change infrastructure, or call an external service. Those are policy decisions with engineering consequences, not sprint decisions.

The distinction matters because local optimization creates company-wide exposure. An engineering manager may accept broad model access to save the team six hours each week. The security lead may object because prompts contain secrets. Finance may discover an uncapped inference bill only after a runaway loop. Legal may learn that customer text crossed an unapproved processing boundary. Each function sees one part; nobody owns the combined choice.

NIST's AI Risk Management Framework puts governance across the organization rather than inside the model team. Its Govern, Map, Measure, and Manage functions are useful because they force an owner to connect context, evaluation, and response. For an SMB, the lesson is practical: one person needs authority to settle tradeoffs that no single department can settle alone.

Keep delivery with the engineering manager. Give AI risk to a named owner whose scope includes data, agency, recovery, cost, and vendor decisions. One person may hold both roles, but the company should record both sets of responsibilities separately.

An SMB needs one accountable AI risk owner

The company needs one accountable AI risk owner, even if several people advise that owner. Committees can review decisions, but a committee cannot be the person called when an agent deletes records at 2 a.m. Shared input is healthy; shared accountability usually means nobody can make the final call.

The owner needs explicit authority to:

• approve or reject model and vendor access;
• set autonomy levels for each use case;
• require rollback tests before production access;
• establish spending limits and escalation paths;
• suspend an AI workflow without waiting for the next leadership meeting.

The CEO should appoint this person in writing. A one-page charter is enough. It should name the systems in scope, the decisions the owner controls, the people who must be consulted, the exceptions that require CEO approval, and the review cadence. The charter should also say that product deadlines do not override a stop decision.

A fractional CTO fits when the role requires executive judgment for a few days per month rather than daily people management. The fractional leader writes the control model, resolves cross-functional disputes, reviews high-consequence exceptions, and teaches the engineering manager to operate the system. The engineering manager still runs the team and applies the controls during normal delivery.

Do not hire a fractional CTO merely to give an existing manager a more impressive supervisor. Hire one when there is an authority or experience gap. If your engineering manager already controls architecture, security, vendor risk, budgets, incident response, and executive tradeoffs, give that manager the AI risk charter and hold them accountable. Adding another title would slow decisions.

The owner also needs access to the CEO. If sales can promise an AI feature, finance can cut its safeguards, or a founder can grant a vendor access without consulting the owner, the role is decorative. A useful test is simple: can this person stop a launch that meets its date but fails its rollback test? If not, nobody truly owns the risk.

Vendor selection belongs under the same owner. Procurement may negotiate terms, security may review controls, and engineers may test output quality, but someone must decide whether the combined service is acceptable for the use case. That decision should cover subcontractors, retention, account administration, incident notice, model changes, export options, and what happens to company data after termination. A good benchmark result cannot compensate for contract terms that conflict with the data policy.

The owner should also define an exception path. Staff will find legitimate cases that the initial policy did not anticipate, and a rule with no practical exception process invites quiet workarounds. An exception request should identify the use case, data, permissions, duration, business reason, compensating controls, and person accepting the residual risk. Time-box every exception. Permanent exceptions are policy changes and deserve a full decision.

Publish approved routes where staff can find them, and remove personal accounts from company workflows.

Model access follows data and consequence

Model access should depend on the sensitivity of the input and the consequence of the output, not on which model happens to be popular. A public marketing draft and a production database repair may use similar technology, but they should never share the same access path.

Build a small access matrix with use cases as rows. For each row, record the permitted model or vendor, allowed data classes, retention setting, region if relevant, credentials, tools, output destination, and approver. Do not start with a list of models. Start with work the company actually performs.

A useful classification has four levels:

1. Public work includes information already approved for publication. Users may use approved general-purpose models without privileged tools.
2. Internal work includes plans, source code, and routine business records. Users need company accounts, defined retention terms, and no production credentials.
3. Confidential work includes customer content, security findings, financial details, or unreleased intellectual property. Only specifically approved workflows may process it.
4. Restricted work includes secrets, authentication material, regulated records, and actions that can materially change production. Models should not receive it unless the company has designed and approved a narrow exception.

Classification alone is not enough. Track where output can go. A model that reads confidential support tickets and produces a private summary has one risk. The same model posting a reply directly to a customer has another. Input access and action access need separate approvals.

Use a policy record that an engineer can read during implementation. A minimal entry can look like this:

use_case: support_reply_draft
owner: customer_operations
model_access:
  data_classes: [internal, confidential_customer_text]
  allowed_accounts: [company_managed]
  training_on_inputs: false
actions:
  read: [ticket_body, approved_help_articles]
  write: [private_draft]
  prohibited: [send_reply, issue_refund, change_account]
review:
  human_approval: every_output
  expires_on: 2026-10-01

This fragment prevents a familiar failure: a drafting experiment quietly becomes an autonomous support agent because someone adds a send permission later. The prohibited actions make that boundary visible in code review. The expiry date forces a fresh decision instead of turning a pilot into permanent infrastructure by neglect.

The risk owner approves the matrix. Security validates data handling and credentials. Legal reviews contractual and regulatory constraints. The engineering manager implements access and confirms the team follows it. That split gives specialists a veto in their domain without making them accountable for the whole operating decision.

Autonomy should rise one reversible step at a time

An AI workflow should earn autonomy through evidence, and each increase should remain reversible. Teams get into trouble when they treat autonomy as a binary choice between a chat window and a fully independent agent. There are several useful levels between those extremes.

Start by separating recommendation, preparation, execution, and persistence. A model can recommend a database query without running it. It can prepare a pull request without merging it. It can execute a reversible change without gaining permission to make that permission permanent. Each verb carries a different consequence.

I use five autonomy levels:

• Level 0 permits analysis only, with no tools and no writes.
• Level 1 permits drafts or proposed actions that a person must approve.
• Level 2 permits low-impact reversible actions within a narrow scope.
• Level 3 permits bounded workflows with sampled human review and automatic stops.
• Level 4 permits broad independent action only where monitoring and recovery have already proved reliable.

Most SMB workflows should live at Levels 1 or 2. Level 3 can make sense for repetitive work such as classifying routine tickets or updating a test environment. Level 4 is rare because the control system often costs more than the labor it removes. Autonomy should save more operational effort than it creates.

OWASP's guidance for applications using large language models calls out excessive agency: a model gets more functionality, permissions, or autonomy than the use case requires. The common recommendation to "put a human in the loop" is too vague to fix it. You must name the exact action that requires approval, what evidence the reviewer sees, and what happens when the reviewer does nothing.

An approval rule should specify four things: trigger, approver, evidence, and timeout. For example, a deployment agent may update a staging service after tests pass. Production deployment requires the on-call engineer to see the diff, test result, target environment, estimated cost change, and rollback command. If nobody approves within 30 minutes, the request expires.

Avoid approval theater. If a reviewer receives twenty prompts each day and each prompt hides the material change under a long model explanation, approval becomes reflexive. Reduce the number of approval points, show the relevant diff, and reserve human review for consequences a person can judge. A human click does not make an unsafe workflow safe.

The AI risk owner sets the level and the evidence required to move upward. The engineering manager may operate within that level and request a change. High-impact increases should require security or finance input, depending on the consequence. Record the decision, the evidence, and the next review date.

Rollback must work before autonomy expands

Rollback is an operating capability, not a sentence in a policy. Before an agent receives permission to change production, the team should demonstrate how to detect the bad action, stop further actions, restore a known state, and reconcile any effects that cannot simply be reversed.

Version control makes engineers overconfident here. Reverting a code commit does not unsend an email, recover a disclosed secret, reverse an external payment, or tell a customer that an automated answer was wrong. Technical rollback and business repair are separate tasks. Every use case needs both considered.

Walk through a support agent failure. The agent reads a billing complaint, misclassifies the account, issues a credit, changes the subscription, and sends a confident reply. A code rollback changes none of those records. Recovery needs an idempotent compensation operation for the credit, a known prior subscription state, a correction message, an audit event tying the steps together, and a stop that prevents the agent from processing the next ticket.

For each autonomous write, require:

• a durable record of input, decision, tool call, result, and policy version;
• a correlation ID across model and business-system events;
• a tested stop control that disables new actions quickly;
• a restore or compensation procedure with a named operator;
• a rule for notifying affected customers or staff.

Logs should describe actions in business terms. Token traces help debug the model, but an incident commander needs to know that order 1842 was refunded, account 771 changed plan, and message 993 was sent. Store only the content required for investigation because indiscriminate prompt logging can create a second copy of sensitive data.

A useful audit event has a predictable shape:

{"event":"subscription.change","actor":"agent:retention-v2","policy":"retention-prod-3","correlation_id":"req_8f31","target":"account_771","before":"standard","after":"paused","approval":"apr_204","result":"success"}

The owner should ask the team to restore a test case, not merely show a rollback document. Run the exercise before launch and after material changes to tools, permissions, or data flow. If recovery depends on the one engineer who built the agent remembering an undocumented command, recovery does not exist.

Spending limits belong beside permissions

AI spending limits should work like access controls: explicit, layered, observable, and enforced before the bill arrives. Finance owns the company budget, but the AI risk owner decides how technical limits map to each workflow. The engineering manager implements alerts and stops.

Set limits at four scopes when the provider and architecture allow it: per request, per workflow run, per day, and per month. A monthly account cap alone will not stop one looping agent from consuming the budget needed by every other team. A per-request cap alone will not catch thousands of individually cheap calls.

Dollar limits are necessary but incomplete. Constrain the units that cause cost: model choice, input size, output size, retry count, tool iterations, concurrent jobs, and queue depth. An agent that can recursively delegate work needs a depth limit. A batch job needs a maximum item count. A fallback route should not silently switch every request to the most expensive model.

Tie each workflow to a cost owner and a business metric. A support summarizer might have a cost per ticket ceiling. A coding agent might have a weekly team allowance and a separate cap for long-running repository analysis. The exact amount depends on company economics, so copying another startup's dollar limit is lazy governance.

Use three responses as spend rises. An early alert tells the workflow owner to inspect the change. A soft limit blocks expensive modes or reduces concurrency. A hard limit stops new work, except for explicitly exempted recovery tasks. Write down who may raise each limit and for how long.

Finance should see a forecast and actual spend by workflow, not one vendor invoice. Engineering should see unit use and failure patterns. The risk owner should review unexpected variance because it may indicate a loop, abuse, routing error, or successful adoption. Cost growth is not automatically bad, but unexplained cost growth is never acceptable.

Do not solve spend risk by requiring the CTO to approve every minor increase. Define bands. The engineering manager can move within an approved operating budget. The risk owner approves temporary exceptions and changes to unit economics. The CEO or finance lead approves a material change to the company budget. This keeps ordinary delivery moving while protecting the company from open-ended commitments.

The engineering manager and fractional CTO need a written split

The engineering manager should own daily execution while the fractional CTO owns the control system and executive tradeoffs. Write that split down because friendly verbal agreements collapse during a launch or incident.

A practical division looks like this. The engineering manager inventories use cases, implements access, maintains evaluations, monitors workflows, runs rollback exercises, and reports exceptions. The fractional CTO defines policy, approves high-consequence access, resolves disputes among functions, reviews vendor and architecture choices, chairs serious AI incidents, and reports residual risk to the CEO.

Security, legal, finance, and business owners still have direct responsibilities. Security controls identity, secrets, and monitoring. Legal decides whether contracts and data terms permit a use. Finance owns total budget. The business owner defines acceptable outcomes and handles customer repair. The fractional CTO connects those judgments and makes the technical decision when they conflict.

Use a decision register rather than a slide deck. Each entry should include the question, owner, consulted people, decision, reason, evidence, expiry date, and rollback requirement. This record keeps an exception from turning into folklore.

Incident authority needs the same clarity. The on-call engineer should be able to isolate a workflow immediately without seeking executive permission. The engineering manager coordinates technical containment and recovery. The fractional CTO decides whether related workflows must stop, whether the company can safely resume, and which policy or architecture change follows. The business owner handles operational repair, while the CEO decides external disclosures after receiving legal advice. Writing these roles before an incident saves an argument when minutes matter.

decision: allow_agent_to_merge_low_risk_dependency_updates
accountable: fractional_cto
responsible: engineering_manager
consulted: [security_lead, service_owner]
conditions:
  - tests_pass
  - no_permission_changes
  - dependency_is_on_approved_registry
  - rollback_completed_in_staging
expires_on: 2026-09-30

Review high-consequence workflows monthly at first and lower-risk workflows quarterly once their behavior is stable. Review immediately after an incident, vendor change, new tool permission, major model change, or material shift in volume. Calendar-based review alone misses the changes that alter risk.

The fractional arrangement fails when the outside leader only attends status calls. The role needs access to architecture, contracts, incident records, cost data, and the people doing the work. It also needs scheduled decision time. A fractional CTO who cannot inspect evidence or issue a stop is an adviser, not the owner.

A 30-day control plan can expose the gaps

Thirty days is enough to establish ownership and control the highest-risk AI use cases, though it is not enough to perfect every workflow. The goal is to replace invisible decisions with named owners, enforced boundaries, and tested recovery.

During the first week, inventory active and planned AI use. Interview engineering, sales, support, marketing, finance, and operations because unofficial tools often sit outside the engineering manager's view. Record data inputs, model accounts, tools, outputs, business owner, monthly spend, and whether the workflow can act without approval. Disable any unknown workflow with production credentials or restricted data until someone accepts ownership.

In the second week, classify data and autonomy. Create the access matrix, assign an autonomy level, and identify prohibited actions. Name one accountable risk owner and publish the charter. Do not spend the week writing a broad AI ethics statement. It will not tell an engineer whether an agent may refund an invoice tomorrow.

In the third week, test controls on the highest-consequence workflows. Verify account boundaries, secret handling, approval evidence, spend stops, audit events, and rollback. Run at least one failure injection: deny a tool call, return malformed model output, simulate a provider timeout, or trigger a cost threshold. Watch what the system and the operator actually do.

In the fourth week, close the most dangerous gaps and create the decision register. Give every unresolved risk an owner, due date, temporary limit, and stop condition. Report residual risk to the CEO in plain terms: what the workflow can do, what can go wrong, how quickly the company can detect it, and what recovery requires.

The output should fit in a small operating pack: charter, use-case inventory, access matrix, autonomy rules, spend policy, rollback runbooks, and decision register. If the process produces fifty pages but engineers cannot find the production approval rule, it has failed.

The first month should also establish measures. Track unauthorized access attempts, approval rejections, rollback test results, policy exceptions, spend variance, and incidents by workflow. These are operating signals, not vanity totals. A rising rejection rate may mean the model is deteriorating, the policy is too strict, or users are attempting riskier work. Investigate before changing the limit.

Hire fractionally when authority and experience are missing

An SMB should hire a fractional CTO for AI risk when no current leader can make cross-company technical decisions with executive authority. The strongest signal is not company size. It is a repeated gap between what the AI workflow can do and what any one leader is authorized to control.

You probably need the role when models already touch confidential data, agents can write to business systems, spending crosses several teams, or leaders keep reopening the same access argument. You also need it when the engineering manager understands the implementation but has never designed incident recovery, vendor controls, and executive risk acceptance.

You probably do not need it when AI use stays limited to public information and human-reviewed drafts, the engineering manager already holds a CTO-level charter, or a capable security and architecture leader owns the full decision. In those cases, document the owner and spend the money on implementation.

Define the engagement around decisions and evidence, not hours in meetings. In the first phase, expect a use-case inventory, policy boundaries, tested rollback for the highest-risk workflows, a spending control model, and a responsibility split the CEO has approved. Ongoing work should focus on exceptions, incidents, material changes, and coaching the internal manager.

Ask candidates how they would bound one of your real workflows. A capable answer will separate input access from action access, define evidence for approval, name a stop mechanism, and ask about unit economics. Be cautious if the answer stays at the level of principles, tool enthusiasm, or a generic policy template. This job requires decisions that engineers can implement and executives can defend.

My Team & AI Audit on oleg.is is a $5,000, five-business-day way to identify these gaps, with a guarantee of at least $50,000 per year in identified savings or the audit is free. The service can lead into fractional CTO oversight when the company needs someone to own the changes, but the audit should still leave management with concrete decisions even if we do no further work together.

Do not leave AI risk with "the leadership team." Name one owner, give that person stop authority, and test the controls against a real failure. If your engineering manager cannot hold that mandate, bring in fractional leadership until someone inside the company can.