AI GovernanceChange ManagementQuality SystemsWorkflow Design

Who Belongs in the Room When an AI Workflow Is Redesigned

SC
Sean Cummings
·October 6, 2026·4 Min Read
Who Belongs in the Room When an AI Workflow Is Redesigned

When a team redesigns a workflow around an AI agent, it decides what the agent may do on its own and what record it leaves behind, and those are compliance decisions. That work can be divided so that operations, IT, data and quality each own a defined part of it.

Why the redesign session decides your compliance posture

In a traditional software project, quality or compliance usually meets the system at validation. Operations and IT write the requirements, the system gets built, and the quality team tests it against those requirements and signs off. That sequence holds up when the software only does what it is explicitly told. An AI agent adds a different kind of design decision, which is how much the agent is allowed to do on its own at each step.

Can the agent approve a supplier change under a dollar threshold? Can it route a customer complaint without review, or post a journal entry? Each of these questions is about accountability and evidence, and they are the questions an auditor or examiner will eventually ask. If they get answered in a process-mapping session run by operations and IT, the quality team receives them at validation as settled facts. Objecting at that point means rework, and the person who objects gets blamed for the slipped date.

The record works the same way. Suppose an agent drafts a deviation summary that a person reviews and signs. For FDA-regulated firms, the electronic records requirements in 21 CFR Part 11 attach to what was signed and by whom. Whether the system keeps the agent's draft, the inputs it used and the reviewer's edits is a design choice made early in the project. Adding an audit trail to a workflow that was designed without one is slow and expensive.

What each function should own

Collaboration becomes useful when each function owns a specific decision. Operations owns the process: the actual steps, the exceptions that come up every week, and what a person does when the agent's output is wrong. IT owns integration and access. That means which systems the agent reads from and writes to, under what credentials, and what happens when a legacy system is down. The data function owns the inputs: where each data element comes from, how current it is, and who corrects it when it is wrong.

Risk or quality owns the autonomy boundaries and the record. For each step, they decide whether the agent acts alone, proposes an action for a person to approve, or stays out entirely, and they decide what evidence is retained. This gives the quality lead a defined deliverable with their name on it. It also makes disagreements specific. If operations wants the agent to close low-risk complaints automatically and quality does not, the argument is about a threshold on one step, and a group can settle that in a meeting.

The Blackstone+Cullen piece also asks whether mid-market companies need an AI center of excellence. For a company that already runs a quality system, I would start with the bodies you have. A change control board or management review already brings these functions together under a documented procedure. Adding AI workflow decisions to that group's charter is usually easier to defend to an auditor than a new committee with no procedure behind it. The same article describes AI change as cyclical, with governance revisited as the organization learns. That fits naturally with a board that already meets on a schedule.

Writing down approval logic before you automate it

Most regulated workflows contain approval logic that nobody has ever written down. Laminar's work for Ventura Foods shows what surfacing it involves, although that project did not involve AI. Ventura Foods replaced a legacy RPG mainframe and manual approvals for new product development with a web workflow application covering facilities in the U.S., EU and Mexico, including logic for choosing which site would manufacture a product. Building it meant stating the approval routing and site selection logic precisely enough for software to apply it. An AI workflow requires the same exercise plus one more step, which is deciding which of those judgments a machine may make.

There is real friction here. Quality teams in mid-market companies are thin, and audits, CAPAs and complaint investigations already fill their calendars. Some staff will be skeptical, often for good reason if a past system created more review work than it removed. A short working session with the right four people early in the project still costs far less than a validation cycle that sends the design back to the start.

Next steps

  • Before your next AI workflow design session, name one person each from operations, IT, data, and quality or risk, and put all four on the invitation.
  • Map the workflow step by step and assign each step a mode: the agent acts, the agent proposes and a person approves, or a person does it alone. Have quality sign that table.
  • For each step the agent touches, write down what is retained, including the inputs, the agent's output, any human edits and the approver's identity.
  • Check whether your change control procedure covers changes to an agent's instructions, thresholds or underlying model. If it does not, draft the amendment before go-live.
  • Dealing with a similar challenge?

    We work with mid-market companies in regulated industries to build AI workflows that actually hold up.

    Let's Talk
    SC

    Sean Cummings

    Founder of Laminar Consulting Services. Specializes in AI workflow automation for regulated industries — medical device, financial services, and complex logistics operations.

    ← Back to all postsWork With Us