AI Infusion vs. AI Transformation:When to Improve the WorkWhen to Redesign the Workflow

AI infusion starts with the existing process and workflow and asks how AI can improve them. The roles and responsibilities of business analysts, product managers, and engineers largely remain in place, while AI enhances how people perform their work. AI becomes a tool inside the existing workflow.

Consider a business analyst working through a hypothetical 300-page requirements document. With AI infusion, the analyst might use an LLM to:

• summarize individual sections
• identify functional and non-functional requirements
• compare two versions of the document
• find potentially conflicting requirements
• extract dependencies
• generate questions for stakeholders
• draft JIRA stories and acceptance criteria
• reorganize information for different audiences

Instead of manually reviewing dozens of pages looking for changes between two versions of a specification, the analyst could ask the model to identify requirements that were added, removed, or materially modified and explain the potential downstream impact.

The analyst could also take a loosely written requirement such as “merchants must be assigned the appropriate Merchant Category Code before activation” and ask the model to draft a JIRA story, proposed acceptance criteria, dependencies, assumptions, and questions that still need to be resolved.

The workflow has not fundamentally changed. The analyst is still orchestrating the work, deciding what to ask, evaluating the output, and determining what happens next. But the analyst may be able to complete that work substantially faster and explore the information from many more perspectives.

The AI helps the human reason, summarize, organize, generate, and analyze. This can create meaningful value without requiring the company to redesign its applications, data architecture, or operating model. For many organizations, that is exactly the right place to begin.

Where Prompt Engineering Fits

Prompt engineering is particularly important in AI infusion because the human still orchestrates the workflow. The business analyst decides what problem to solve, what information the model should receive, how the task should be broken down, what the output should look like, and how the result should be evaluated.

Good prompting is therefore much more than finding clever wording. It is about giving the model enough structure and context to perform a task reliably. This can include:

• defining the objective and, when useful, the role the model should perform
• giving the model the relevant business context and source material
• breaking a large problem into smaller, more focused tasks
• specifying what the model should and should not infer
• defining the desired output format
• providing examples of the type of output expected
• asking the model to distinguish facts from assumptions or interpretations
• requiring the model to identify uncertainty, missing information, or conflicting evidence
• iterating on the results and refining the instructions
• asking the model to critique or validate earlier outputs

Prompt engineering gives the model more structure:

• a clearer objective
• tighter scope
• explicit constraints
• a defined output format
• boundaries on what the model should infer
• a more disciplined sequence of tasks

A business analyst working with a large requirements document could simply ask:

The model may produce a useful response, but the task leaves many decisions unspecified. What constitutes a requirement? Should functional and non-functional requirements be separated? Should assumptions be included? Should the model infer requirements that are implied but never explicitly stated? How should dependencies, conflicts, and unresolved questions be handled?

A more deliberate approach might break the work into stages.

Stage 1: Extract

Stage 2: Analyze

Stage 3: Produce

This type of decomposition can produce a more disciplined result than asking the model to perform the entire analysis in a single step. It also makes the output easier for the analyst to inspect and correct before moving to the next stage.

From Prompt Engineering to Agent Skills

Prompt engineering can also make the interaction more repeatable. Instead of every analyst inventing a new prompt each time, organizations can develop reusable prompts, templates, output schemas, examples, and evaluation criteria for common tasks. OpenAI’s current guidance similarly treats production prompts as versioned application code and recommends representative fixtures, tests, and evaluation checks before prompts change. See OpenAI’s prompt engineering guidance.

Agent skills take this idea a step further by packaging some of that reusable organizational know-how into a form an agent can apply when performing a particular task.

A skill is a reusable package of instructions and supporting resources that teaches an AI system how to perform a particular task in a consistent way. Instead of explaining the process from scratch every time, an organization can capture its preferred method once and make it available whenever that type of work needs to be performed. A skill can include instructions, examples, reference material, templates, and even executable scripts that help the agent perform the task. Microsoft’s current Agent Skills implementation describes skills as portable packages of instructions, scripts, and resources that give agents specialized capabilities and domain expertise.

A requirements-analysis skill, for example, might encode the organization’s standard method for extracting requirements, identifying assumptions and conflicts, generating clarification questions, and producing JIRA-ready output.

In that sense, a skill can turn good prompt-engineering practices from something an individual analyst remembers to do into reusable organizational know-how.

Yet in this AI Infusion scenario, the basic operating model remains the same. The analyst decides when to invoke AI—for example, by manually invoking a requirements-analysis skill—provides the relevant context, evaluates the response, and determines the next step. The skill makes the AI more capable and consistent, but it does not by itself redesign the workflow.

Retrieval-Augmented Generation (RAG): Grounding AI in Enterprise Knowledge

Prompting alone has a limitation: enterprise work depends on enterprise information.

The limitation becomes apparent when the analyst asks the LLM a question whose answer is not contained in the information provided to the model. The relevant business rule might instead be buried elsewhere in the 300-page document, or in another specification entirely. That is where efficient retrieval to bring information to the LLM becomes important.

Policies, requirements, architecture documents, product specifications, contracts, support procedures, regulations, historical decisions, and institutional knowledge often live across hundreds or thousands of documents and systems. That is where retrieval-augmented generation, or RAG, techniques can help.

Instead of expecting the LLM to know an organization’s proprietary information, a RAG architecture retrieves relevant information from an enterprise knowledge source and provides that information as grounding context for the model. Microsoft describes RAG as retrieving relevant chunks from an organization’s documents and sending them with the user’s question to the LLM. See Microsoft’s overview of RAG.

RAG can support both infusion and transformation. In the infusion approach, the analyst might ask: “What are the requirements related to transaction reversals?” The system retrieves the relevant sections and helps the analyst interpret them.

As the organization moves toward transformation, that same retrieval capability can become a reusable enterprise knowledge layer used by applications, copilots, agents, and automated workflows. The knowledge layer is no longer simply helping someone find a document. It becomes shared infrastructure through which AI-enabled applications and workflows can access governed enterprise knowledge.

For the architecture and controls behind that layer, read Production RAG: Beyond a Vector Database.

There is a more fundamental question we can ask: Why is a 300-page document the primary way this organizational knowledge is represented and consumed in the first place?

The document exists for good reasons. Historically, organizations needed a durable artifact that people could circulate, review, approve, version, audit, and hand from one team to another. But the document is ultimately a container for the underlying knowledge.

The actual knowledge is made up of smaller things:

requirements, decisions, assumptions, business rules, dependencies, exceptions, source evidence, owners, approvals, mappings, tests, and relationships between all of them.

Modern requirements-management systems already recognize this distinction. IBM DOORS, for example, treats requirements as structured artifacts that can be linked to other requirements, development artifacts, and tests, creating end-to-end traceability rather than treating the document itself as the atomic unit of knowledge. See IBM’s requirements traceability documentation.

AI transformation allows us to reconsider the “large document” architecture. Instead of treating the document as the system of record, an organization could maintain a living requirements knowledge system in which those elements exist as structured, connected information. The 300-page document could still be produced when needed, but it would become an output of the knowledge system rather than the knowledge system itself.

Structured requirements knowledge is not an AI invention. The new capability is that AI can help populate, reconcile, interrogate, update, and act upon that structured knowledge continuously.

AI transformation begins with a different question. Instead of asking, “How can AI help an analyst work through this 300-page document faster?” we ask: “Why does an analyst need to manually orchestrate this entire process in the first place?”

Imagine that the system of record is a living requirements knowledge system.

Instead of treating the requirements document as the primary place where knowledge lives, the organization maintains the individual requirements, decisions, rules, dependencies, exceptions, evidence, approvals, and relationships between them as structured information. The document can still be produced when needed, but it becomes one view of that knowledge rather than the knowledge system itself.

A requirement in that system might exist as something like this:

Requirement:

A merchant must be assigned and validated against the appropriate Merchant Category Code before activation

Source:

Merchant onboarding requirements workshop

Related specification:

Merchant Classification Standard §5.2

Dependency:

Merchant underwriting and classification

Exception:

Merchants with ambiguous or multiple business activities require manual classification review

Prior precedent:

Similar classification resolved during a previous portfolio conversion

Decision owner:

Merchant Risk Operations

Status:

Approved

Implemented by:

Merchant classification rule 87

Test cases:

TC-427, TC-428

Then the 300-page business requirements document becomes merely one possible view of that knowledge. You could still generate a BRD when someone needs one for governance, audit, legal review, a steering committee, or a contractual milestone. But the BRD is no longer where the knowledge lives. It is a rendered snapshot of a continuously maintained knowledge system.

Imagine that the requirements documents, architecture specifications, implementation guides, business glossary, JIRA backlog, regulatory requirements, and historical decisions are incorporated into a governed knowledge layer. Now an AI-enabled workflow could:

• detect a newly submitted or changed requirement
• retrieve related requirements and architectural constraints
• identify affected systems and dependencies
• detect potential conflicts
• propose updates to JIRA stories
• generate acceptance criteria
• identify regulatory or security considerations
• route unresolved questions to the appropriate stakeholder
• maintain traceability between the source requirement and downstream implementation
• request human approval before consequential changes are made

At this point, the analyst is no longer manually initiating every AI interaction. The workflow itself has become AI-enabled.

Modern agent frameworks increasingly support this kind of graph-based orchestration, where agents, deterministic functions, checkpoints, and human approvals can participate in the same multi-step workflow. Microsoft Agent Framework, for example, supports explicit workflow graphs, checkpoints, and human-in-the-loop gates. See Microsoft Agent Framework workflows.

That is the distinction we find most useful:

It is important to note that transformation does not necessarily mean maximizing autonomy. It means redesigning the workflow and division of responsibility among humans, AI, and software. In some transformed processes, humans may still make many of the consequential decisions.

The document-centric workflow

Knowledge is captured in meetings, emails, subject-matter experts’ heads, spreadsheets, JIRA tickets, and documents. Humans manually consolidate some of it into a linear handoff:

Meeting → notes → analysis → BRD → review → revisions → approval → JIRA → implementation → testing

The document becomes the coordination mechanism.

The transformed workflow

AI continuously helps turn those inputs into structured organizational knowledge:

meetings + emails + specifications + historical decisions + source data + existing requirements
↓
living requirements and decision system
↓
relationships + provenance + conflicts + exceptions + dependencies + approvals
↓
different outputs generated as needed
↓
BRD | JIRA stories | acceptance criteria | test cases | data mappings | executive summaries | implementation rules

That is much closer to the AI operating-model shift Microsoft describes: enterprise AI grounded across business data and systems, with agents, workflows, governance, and human judgment operating together rather than AI simply being bolted onto isolated tasks. See Microsoft’s view of the system surrounding enterprise AI.

Notice what happens to RAG in this architecture.

AI Infusion:
Human → asks AI a question → RAG searches a 300-page BRD → answer

AI Transformation:
System → continuously reasons across requirements, decisions, meetings, historical precedents, and implementation artifacts → humans intervene where judgment is required

RAG may still be underneath both systems. But in the second case, RAG is infrastructure, not the transformation itself.

The progression is not simply “chatbot to agent.” Different techniques solve different parts of the problem. The technology becomes progressively more embedded in the operating model.

Swipe horizontally to compare all columns →

Human Oversight Does Not Disappear

One misconception about AI transformation is that greater automation necessarily means removing humans. In many enterprise environments, particularly regulated ones, the opposite is more useful. The goal is not necessarily human removal; it is repositioning human focus.

A person who previously spent hours manually finding, copying, comparing, and reorganizing information may instead spend more time reviewing exceptions, resolving ambiguity, approving consequential actions, and applying judgment where judgment matters most.

Human-in-the-loop patterns allow an automated workflow to pause when approval, clarification, or escalation is required. The important architectural question becomes: Where should autonomy stop?

A low-risk internal summarization task may require very little intervention. Changing a customer account, executing a payment, modifying production code, making a regulated decision, or communicating externally may require explicit authorization. The right level of human oversight should depend on the consequence of being wrong.

Governance Must Evolve With Autonomy

Governance should not be something added after the AI solution is built. As systems gain access to more data, more tools, and more ability to take action, governance becomes part of the architecture itself. That can include:

• identity and access controls
• approved data sources
• sensitive-data boundaries
• model and prompt versioning
• evaluation thresholds
• tracing and observability
• audit trails
• tool permissions
• escalation rules
• fallback behavior
• human approval
• incident management

NIST’s AI Risk Management Framework organizes AI risk management around Govern, Map, Measure, and Manage, and its Generative AI Profile extends those principles specifically to GenAI systems. The framework emphasizes managing risk across the design, development, deployment, and use of AI—not merely reviewing the system at the end. See the NIST AI Risk Management Framework.

Organizations do not have to choose between a small productivity improvement and a massive transformation program. A more pragmatic journey often looks like this:

1. 1. Personal productivity

   Employees use AI through prompting, summarization, analysis, drafting, and research.

2. 2. Knowledge grounding

   RAG connects AI to governed enterprise information.

3. 3. Workflow integration

   AI connects to APIs, business applications, and enterprise systems.

4. 4. Agentic orchestration

   Agents and deterministic services coordinate multi-step tasks with explicit controls and escalation paths.

5. 5. Operating-model transformation

   Roles, processes, metrics, governance, and human responsibilities are redesigned around the capabilities of the new system.

This progression is illustrative rather than prescriptive: different use cases within the same organization may sit at different stages, and not every use case needs, or benefits from progressing all the way to operating-model transformation.

Each stage teaches the organization something:

• Which use cases generate value?
• Which data is trustworthy?
• Where do models fail?
• Which tasks require human judgment?
• Which integrations matter?
• What level of autonomy is acceptable?

That learning makes the next stage safer and more valuable.

There are two opposite mistakes organizations can make.

The first is calling AI infusion “transformation.” Giving every employee access to an LLM can create substantial productivity gains, but the underlying business process may remain exactly the same.

The second mistake is insisting on transformation when infusion would solve the immediate problem. Not every use case needs an agentic architecture, enterprise knowledge graph, orchestration layer, and redesigned operating model.

Sometimes helping an analyst complete a task in 30 minutes instead of three hours is already a meaningful business outcome.

That is where the two approaches become complementary. AI infusion gives organizations a way to learn and generate near-term value. AI transformation uses those lessons to redesign how work gets done.

Between them sits the real engineering challenge: connecting models to enterprise knowledge and systems while introducing the governance, measurement, and human oversight necessary to make AI useful in the real world.

We need to expand our thinking beyond “how much AI can we add to the work?” and consider whether AI gives us an opportunity to redesign how the work should be done. That means recognizing the value of both AI infusion and AI transformation, and deciding where infusion is sufficient and where transformation should begin.

Next in this series: In Part Two, we’ll take the concept of AI Transformation further and show what a living requirements knowledge system could look like in practice, using a merchant-acquiring workflow as a concrete example.