Enterprise AI · Architecture · Strategy & delivery
AI Solutions Architecture: Building Enterprise AI That Works
The work behind useful AI: choosing the right problem, connecting reliable information, controlling what the system can do and giving people something they can actually trust.
There is a particular moment in an AI demonstration when everyone leans forward. The system finds an answer, summarizes a complicated document or completes a task that used to involve several windows and somebody named Linda who knows where everything lives.
It is a good moment. The possibility is real.
Then someone asks whether it can work with the actual company’s information, inside the actual company’s permissions, without accidentally treating last year’s policy as current. The room becomes a little quieter.
An AI solutions architect works in that quieter part of the conversation. The role connects a business objective to a system that can be evaluated, operated, maintained and changed. An enterprise AI consultant may also help choose the objective, assess readiness, align decision-makers and guide the organization through the work.
That means understanding models. It also means understanding data, identity, integrations, budgets, human behavior and the peculiar durability of a spreadsheet that everyone claims is temporary.
My interest in this work comes from the intersection of science, technology and communication. Research teaches me to examine evidence. Creative work helps me imagine a more useful experience. Enterprise systems experience reminds me that an elegant idea still has to survive contact with the way the business operates.
The role owns the reasoning behind the system.
An AI solutions architect translates an intended outcome into technical decisions: data sources, retrieval, model use, tool access, integration, deployment, evaluation and operational controls. An enterprise AI consultant often works across a wider decision process, including opportunity selection, governance, organizational readiness and implementation planning.
In practice, one person may contribute to both. What matters is that the engagement defines the decisions they own, the specialists they need and the evidence required before the organization commits further.
The architect should be able to explain why the proposed system exists, what it is allowed to do, where its information comes from, how it fails and who takes responsibility when it does. A diagram full of familiar logos answers none of those questions by itself.
| Responsibility | Useful deliverable | Decision it supports |
|---|---|---|
| Business alignment | A measurable objective, baseline and bounded use case. | Is this a worthwhile problem to solve? |
| Data and access | Source inventory, ownership, lineage and permission model. | Can the system use the right information for the right person? |
| Architecture | System boundaries, interfaces, deployment choices and tradeoffs. | What should we build, buy or avoid? |
| Evaluation | Representative test cases, acceptance criteria and failure analysis. | Does it perform well enough for this use? |
| Operations | Monitoring, cost controls, recovery procedures and named owners. | Can we run it responsibly after launch? |
| Adoption and handoff | Training, support, documentation and maintainable ownership. | Will the organization use it and keep it working? |
Companies can engage outside help when they need concentrated expertise for a defined decision or delivery period. That does not establish that contracting is always cheaper or that internal leadership is unnecessary. The right arrangement depends on capability, urgency, continuity and what the business must own after the engagement ends.
My broader AI and machine learning consulting work starts with that practical question: what would a useful result look like here?
Begin with the work someone is struggling to finish.
“We need an AI agent” identifies a possible mechanism. I want to hear about the unfinished work first. Are account managers spending too long locating approved answers? Are analysts reconciling inconsistent records? Is support answering questions that should have been resolved by better information? Does the team need prediction, search, extraction, drafting or an action performed?
Bring the relevant decision-makers into the conversation: the sponsor, process owner, technical owners, people responsible for data and risk, and people who will actually use the system. They often have different definitions of success. Finding that out before development is considerably cheaper.
A useful objective might be: Help authorized service staff find current, source-supported policy answers in less time, without increasing material errors or exposing restricted information. It identifies a user, an outcome and constraints. We would then establish the baseline, measurement method and acceptable thresholds.
I would compare the AI proposal with simpler improvements. Better search, a cleaned-up knowledge base, a rules-based workflow or a conventional predictive model may solve enough of the problem. AI should earn its place in the design.
A practical first-use-case test
Can we identify the user, obtain appropriate data, observe the outcome, limit the consequences of failure and find someone who will own the process? If several answers are missing, the next investment may be discovery rather than development.
Prioritization should consider expected value, frequency, data readiness, integration effort, reversibility, adoption and the cost of getting the answer wrong. A common low-risk task can be a stronger first project than a dramatic high-stakes one. A small scope also makes it easier to discover whether the proposed benefit survives ordinary working conditions.
The first deliverable should include a decision to proceed, revise or stop. A readiness assessment that always recommends the largest possible implementation has an unusually predictable scientific method.
The research question and the user experience belong together.
My background in Earth and Environmental Science taught me to pay attention to measurement, uncertainty, assumptions and the quality of the underlying observations. An environmental model can be sophisticated and still be limited by the data used to build it. Enterprise AI deserves the same skepticism.
If the evaluation set includes only clean documents and cooperative questions, it tells us little about a workplace full of conflicting revisions, abbreviations and people who type half a sentence while answering the phone. The system needs to be tested against the environment it will inhabit.
My psychology background changes the questions I ask about adoption. What will a person assume when a fluent answer appears? Will they understand the difference between a retrieved policy and a generated interpretation? Can they tell what the system has already done versus what it is proposing to do?
As a bestselling author, award-winning storyteller, frequent podcast guest and speaker, I spend a great deal of time thinking about how people understand an idea. Sequence, language and emphasis matter. An answer with a clear recommendation, relevant evidence and an obvious next step can be more useful than a technically accurate wall of text. The interface should help a busy person make a good decision.
I am also decent at sketching on a Wacom tablet. A quick sketch helps me explain a workflow or get an idea out of my head; nobody needs to clear a wall at the Louvre. The Wacom MovinkPad Pro 14 is a current example of the drawing tools available. My creative background is principally in writing, storytelling, podcast guest appearances and speaking. My humor columns have also built a large social following, giving me another way to connect with people through language, timing and shared experience. That background shapes how I make complex systems understandable.
For example, in a policy assistant I would explore showing the applicable policy date and cited passage beside the answer, with a clear route to a human when sources conflict. That is a proposed design choice, not a claim about a past deployment. It gives us something specific to test: whether people make better decisions with less effort.
This connection between evidence and communication also runs through my writing on data, creativity and storytelling. Technical understanding helps establish what is possible. Creative judgment helps make the useful possibility understandable.
Data readiness means knowing what the information is allowed to mean.
A data inventory should go further than counting documents. I want to know which source is authoritative, who maintains it, what it represents, how quickly it changes and who can see it. Ten copies of a policy are not ten independent pieces of evidence.
For documents, inspect format quality, scanned pages, tables, revisions, embedded images, repeated headers and missing context. Optical character recognition can turn a useful source into misleading text. A table can lose its relationship between a value and the column that explains it. Those are information problems before they are model problems.
For structured records, examine identifiers, units, time zones, duplicates, missing values and the meaning of status fields. “Active customer” may mean one thing in the CRM and something else in billing. An AI interface can make that inconsistency easier to query while leaving it completely unresolved.
My experience with ERP, Salesforce and big data makes me attentive to those seams. Integration should preserve business meaning. A record that arrives successfully through an API can still be the wrong record for the decision.
Freshness, deletion and access changes need a route through the system.
If a source changes, how soon should that change appear in retrieval? If a document is removed, what happens to extracted text, indexes and caches? If an employee changes roles, when does the application stop returning information they can no longer access?
I would define these behaviors before ingesting the entire repository. Track the source identifier, revision, effective date, owner and access metadata alongside the content. Establish procedures for conflicts and records that should not be indexed at all.
The word “private” needs particular care. It can refer to source access, network boundaries, hosting, vendor handling or user permissions. Those are separate architectural questions. A private network does not automatically prevent one authenticated employee from seeing another department’s restricted information.
For a data-readiness audit, the useful output is a prioritized list of gaps with owners and consequences. “Your data needs cleaning” is true in many organizations and helpful in approximately none of them without the next sentence.
RAG gives the model evidence. Architecture determines which evidence.
Retrieval-augmented generation, or RAG, retrieves relevant information and supplies it as context for a model’s response. It can connect an application to current or proprietary sources without treating every source update as a model-training exercise. Microsoft’s RAG design and evaluation guidance describes the work as a sequence of design choices that needs systematic evaluation.
For an enterprise system, I would separate the ingestion path from the request path. Ingestion prepares authorized sources for retrieval. A request then identifies the user, determines the permitted search scope, retrieves evidence and asks the model to perform a bounded task with that evidence.
Chunking is a decision about meaning.
Breaking a document into smaller passages can make retrieval more useful, but the passages need enough context to preserve the source’s meaning. A paragraph about an exception may depend on a heading, a definition or the paragraph before it. Arbitrary cuts can make a correct source support an incorrect answer.
I would test different approaches against representative questions. Keep document and section identifiers available so a response can point back to the source. Where tables or forms carry the meaning, preserve their structure or use a representation appropriate to the task.
Search should fit the questions people actually ask.
Semantic retrieval can help with conceptually related wording. Exact identifiers, product codes and unusual names may benefit from lexical matching. Combining approaches and reranking candidates can be useful, but every additional step needs a reason and an evaluation. A sophisticated retrieval pipeline that consistently misses the correct policy is still missing the correct policy.
Measure whether the needed evidence is retrieved, whether irrelevant material crowds it out and whether the final answer uses it correctly. More context is not automatically better. It can increase cost and latency while making it harder to identify the applicable evidence.
Permissions must constrain retrieval before the answer is composed.
I would enforce access through trusted application and data controls, with tests for cross-user and cross-tenant separation. Asking the model to keep a secret after restricted material has already been placed in its context is an inadequate access-control design.
Caches need the same scrutiny. An answer generated for one user should not become available to another through an overly broad cache key. Permission changes must affect the underlying retrieval and caching behavior, not merely the label on the screen.
RAG also needs a sensible response when the evidence is absent, stale or contradictory. A citation is useful only if the cited source actually supports the claim. The application should be able to say it cannot establish an answer and direct the user to the appropriate owner.
Choose the mechanism that fits the failure you are trying to fix.
Longer prompts, retrieval, fine-tuning, predictive models and agents solve different problems. They can work together, but they should not become a compulsory shopping list.
| Need | Possible approach | Question before proceeding |
|---|---|---|
| Find current internal information | Permission-aware search or RAG. | Can we retrieve the authoritative evidence reliably? |
| Extract fields from varied documents | Document processing with a model and deterministic validation. | How do we handle missing values, contradictions and uncertainty? |
| Improve consistent task behavior | Examples, prompt design and potentially fine-tuning. | Do we have representative training and independent evaluation data? |
| Forecast a measurable outcome | A suitable statistical or machine-learning model. | Does the prediction improve an actionable decision? |
| Complete a known sequence | A controlled workflow, with models only where useful. | Which steps actually need probabilistic interpretation? |
| Adapt a plan while using tools | A bounded agent with explicit permissions and stopping rules. | Does the flexibility justify the added uncertainty and cost? |
Fine-tuning changes model behavior through additional training; retrieval supplies information at request time. I would not use fine-tuning as a substitute for enforcing document permissions or maintaining frequently changing source records. A larger context window also does not remove the need to select trustworthy, relevant material.
For forecasting and segmentation, the work may be closer to predictive analytics than to conversational AI. The interface can be conversational while the calculation underneath remains a tested statistical process.
An agent needs boundaries that do not depend on its mood.
In its discussion of effective agents, Anthropic distinguishes predetermined workflows from systems in which the model dynamically directs its process and tool use. That is a useful architectural distinction. Flexibility introduces decisions the application must be prepared to supervise.
An assistant that drafts a response has a different risk profile from an agent that changes a customer record, sends the response and issues a credit. Treat those capabilities separately. “It has access to the CRM” is too vague to be an authorization policy.
I would define tools around narrow business actions, with validated inputs and server-side authorization. Reading an approved account summary, proposing a field update and committing that update should be distinguishable operations. The model can propose an action; trusted systems should determine whether it is permitted.
Make the transaction understandable before making it easy.
Suppose an agent prepares a customer-record correction. The reviewer should see the specific fields, existing values, proposed values, evidence and affected record. Approval should bind to that proposed action. A vague “continue” after several conversational turns is a poor substitute for a clear review of what will change.
Retries also need design. If a downstream service times out, the action may have succeeded even though the response never arrived. Blindly trying again can duplicate a transaction. Use appropriate idempotency, reconciliation and recovery procedures in the application layer.
Set limits for execution time, spending, tool calls and retries. Define escalation conditions and ways to pause or disable execution. An agent that keeps trying indefinitely is not demonstrating perseverance the business should necessarily fund.
Memory is another data system.
If the agent stores information between sessions, decide what may be retained, how it is scoped, when it expires and how it can be corrected or removed. Separate temporary task state from durable user information. A mistaken assumption should not become permanent organizational folklore because the application called it memory.
Multiple agents can sometimes divide work effectively. They also introduce additional handoffs, latency and opportunities for inconsistent state. I would require evidence that the arrangement improves the outcome compared with a simpler design. The organization already has enough committees; the software does not need to recreate all of them.
The content an AI system reads cannot become its permission slip.
Prompt injection can arrive through retrieved documents, emails, webpages or other material the system processes. A malicious passage may try to redirect behavior or induce disclosure. The OWASP prevention guidance describes this as a security problem requiring layered defenses. A carefully worded system prompt is not a complete security boundary.
I would treat external content as untrusted, restrict available actions and validate outputs before they reach other systems. Credentials should be managed through appropriate secrets infrastructure. Tool permissions, network access and data access should be limited to what the application needs.
The same review should include the ordinary application risks around the model: insecure integrations, weak authentication, excessive logs, poorly managed secrets and missing tenant isolation. AI architecture does not replace software security; it adds another place where assumptions deserve scrutiny.
Governance should produce decisions people can follow.
The NIST AI Risk Management Framework and its Generative AI Profile offer reference points for identifying and managing risk. I would use a framework to organize questions and ownership, then translate the relevant work into specific controls and evidence.
For each use case, name the business owner, technical owner, data owner and the people responsible for risk decisions. Record intended use, excluded use, evaluation results, important limitations, change approvals and escalation procedures. The person using the system should know when a human decision is required.
Privacy review needs to examine the complete data path: ingestion, prompts, tool inputs, outputs, logs, caches, evaluation datasets, backups and external providers. Deployment location, contractual handling and technical controls need to agree. The label on the architecture diagram is not evidence that all copies of the data stay inside the intended boundary.
Where regulated information or consequential decisions are involved, qualified legal, privacy and security specialists should establish the applicable requirements. An AI consultant can coordinate and implement agreed controls without representing a prototype as a compliance certification.
Legacy integration is where the business rules introduce themselves.
Most enterprises cannot replace their operating systems simply because a new model arrived. They have ERP platforms, CRMs, document repositories, service desks, warehouses and custom applications that encode years of working practice.
An integration plan should identify systems of record, read and write paths, authentication, field meanings, rate limits, transaction boundaries and failure behavior. A model-generated customer summary should not silently become an authoritative customer record.
I would prefer controlled interfaces that validate business rules and preserve an audit trail. Where an older platform lacks usable APIs, alternatives may include exports, event feeds or carefully constrained automation. The choice should acknowledge brittleness and operational ownership rather than hide it behind a polished chat interface.
Read-only is a useful stage, not a complete definition of safety.
A read-only assistant can still expose information or give a misleading answer. But separating information access from write actions can make an initial scope easier to evaluate. Additional authority should follow evidence, defined controls and a clear business need.
For writes, establish how conflicts are handled when records change during a task. Decide whether an action requires approval, how rollback or compensation works and which system records the final state. Some actions cannot be cleanly reversed; their review requirements should reflect that.
With Salesforce or ERP work, I want the process owner involved in defining what a field change actually means. A status update may trigger a campaign, a fulfillment process or a financial workflow. The AI team needs to understand those consequences before treating it as a harmless text edit.
These questions connect naturally to ERP planning, Salesforce consulting and talent and the forthcoming AI MarTech and automation architecture article. Good integrations preserve the meaning and control of the work as it moves between systems.
Cloud choices should follow the operating requirements.
Managed model services, enterprise API arrangements and self-hosted deployments each create different responsibilities. The comparison needs to include capability, data handling, regional availability, latency, quotas, infrastructure skills, operating cost and the effort required to maintain the system.
A managed service may reduce infrastructure work while leaving the company responsible for application design, permissions and evaluation. A self-hosted model may provide greater control over particular deployment decisions while adding responsibility for serving, patching, capacity and model operations. Neither arrangement eliminates governance.
I would evaluate candidate models on the organization’s tasks, with the surrounding application included. Consider answer quality, structured-output reliability, tool use, latency, cost, context needs, supported languages and the handling of difficult inputs. Model reputation is a starting point for investigation.
Multi-cloud is a choice with a bill attached.
AWS, Azure and Google Cloud can each be relevant to an enterprise architecture. Using more than one should have a concrete rationale: existing systems, contractual requirements, regional needs or a carefully designed resilience strategy. Every additional environment brings identity, networking, monitoring and support work.
Portability deserves similar honesty. An adapter can make APIs look alike without making models behave alike. Prompts, tool calls, evaluation outcomes and safety behavior can change when a provider changes. A fallback needs its own tests, compatible data-handling arrangements and verified capacity.
I would document the failure modes the design is intended to survive. A second endpoint that depends on the same unavailable identity service may provide less resilience than the diagram suggests. Sometimes the best fallback is a simpler search experience or a clear human handoff.
The AWS Generative AI Lens provides a reference for examining operational and architectural concerns across the lifecycle. For firms selling cloud and managed IT services, my marketing and growth consulting helps explain capabilities, reach suitable buyers and support sales.
Evaluate the task, the evidence and the consequences.
A single accuracy percentage is rarely enough. The system may retrieve the right document and misinterpret it. It may answer correctly while citing the wrong source. It may complete a task but violate an access rule. Those are different failures and need different remedies.
I would build an evaluation set from representative work, with appropriate handling of sensitive information. Include common questions, ambiguous questions, missing evidence, conflicting revisions, difficult document formats and requests the system should decline or escalate. Separate development examples from held-out evaluation cases.
Microsoft’s end-to-end RAG evaluation guidance reinforces the need to examine the response in the context of retrieved evidence and expected tasks. The acceptance standard should then reflect the organization’s actual use case.
| Measure | What to inspect | Why it matters |
|---|---|---|
| Task success | Correctly completed tasks under defined acceptance criteria. | A fluent response is not necessarily a useful result. |
| Retrieval quality | Relevant evidence found, irrelevant evidence returned and coverage of answerable questions. | Generation cannot reliably repair missing evidence. |
| Grounding and citation accuracy | Whether claims are supported by the cited source. | A source link should be evidence, not decoration. |
| Appropriate abstention | Unsupported answers versus unnecessary refusals. | The system must balance helpfulness with uncertainty. |
| Access-control tests | Cross-user, cross-role and cross-tenant attempts. | Correct information can still be an unauthorized disclosure. |
| Latency and reliability | End-to-end response time, tail latency, errors and recovery. | Average performance can hide a frustrating working experience. |
| Human review burden | Time to verify, correct and complete the task. | Automation can move work rather than remove it. |
| Cost per accepted outcome | Operating cost divided by results meeting the acceptance standard. | Cheap responses are not always economical outcomes. |
Automated graders can help scale evaluation, but I would calibrate them against expert human judgments. A second model can share weaknesses with the first. Deterministic checks are valuable for requirements such as required fields, permitted values and valid calculations.
Report performance by meaningful task type and consequence. A high average can hide a serious failure in a smaller group. Zero observed failures in a limited test set does not establish zero future risk. Where behavior is variable, repeated testing can reveal instability that a single run misses.
Version the components that affect behavior: model, prompts, retrieval settings, source snapshot, tools and application logic. A change in any of them can justify regression testing. A provider upgrade should be treated as a change to the system, even when the application code stayed still.
The dashboard should support decisions about release, correction and scope. My approach to KPI dashboard design is to make the decision visible before deciding how many charts deserve screen space.
A policy assistant is a good way to discover the real work.
Consider a hypothetical service organization whose employees spend too long finding current internal policies. This example illustrates an approach; it is not a client case study or a promise of results.
I would begin with one policy domain and a named owner. Establish which documents are authoritative and which employees can access them. Observe real questions and the current workflow. The baseline should include lookup time, review time, incorrect answers and escalation.
The first version might retrieve approved passages and draft a cited answer, with no authority to change records or communicate externally. The interface would show the relevant source and effective date, and provide a useful route when the system cannot establish an answer.
Testing would include an expired policy, two conflicting versions, a restricted document, a misleading passage and a question outside the domain. A malicious instruction inside a document would be treated as a security test. Ordinary spelling errors and incomplete questions would be part of usability testing.
If the answer is wrong, diagnose the layer. Did ingestion lose a table heading? Did retrieval miss the current document? Did the application pass an overly broad set of sources? Did the model ignore an exception? Did the user misunderstand a correct response? Each finding suggests a different intervention.
Only after the bounded assistant performs adequately would I consider expanding the source set or adding actions. Wider coverage changes the problem. It should not be treated as a harmless configuration update because the first demonstration went well.
The useful question is whether the whole task got better, including the work needed to check the answer.
The token bill is one line in the economics.
An enterprise AI budget should account for discovery, data preparation, integration, engineering, evaluation, model usage, retrieval, infrastructure, monitoring, human review, support and maintenance. A low cost per generated answer can coexist with an expensive cost per useful outcome.
I would model demand, successful completion, review requirements and operational load together. Include peaks, retries, long contexts, failed attempts and any expensive downstream tools. The usage pattern of an enthusiastic pilot group may differ from the wider organization.
A worked example with the optimistic arithmetic removed.
All numbers below are illustrative assumptions, not market prices or client results.
Suppose a team performs 2,000 eligible tasks each month. If measured end-to-end time falls from 12 minutes to 7 minutes, with review and correction included, the potential capacity released is 10,000 minutes, or about 166.7 hours per month. At an assumed loaded labor value of $45 per hour, that represents $7,500 of monthly capacity value.
2,000 tasks × 5 minutes saved ÷ 60 × $45 = $7,500 potential monthly capacity value.
If recurring operating and support costs are $3,000 per month, the modeled net capacity value is $4,500. A $54,000 initial investment would take 12 months to recover on that basis, assuming those conditions hold.
That is not automatically $4,500 in cash savings. Staff may use the time for other work. The company needs a credible plan for converting released capacity into reduced spending, more throughput or better service, and the financial interpretation should reflect which outcome is actually achieved.
If only half the tasks use the system, the gross capacity value falls to $3,750 under the same time-saving assumption. With the same $3,000 recurring cost, the remaining value is $750 per month and the simple recovery period becomes 72 months. Adoption has changed the investment case more than a small improvement in token pricing would.
I would also test whether speed came at the expense of quality, whether demand grows and whether the review burden changes over time. Count a benefit once. Time saved, increased throughput and revenue enabled may describe overlapping consequences of the same improvement.
Show a downside case and a stopping rule. The point of an investment model is to expose the assumptions that deserve attention before they become an explanation after the money is spent.
Production begins when somebody needs it to work on an ordinary Tuesday.
Operational readiness includes appropriate service objectives, monitoring, incident response, capacity planning and a controlled release process. The team needs to know whether a problem came from retrieval, a model call, a tool, an integration or the source data.
I would trace requests across those boundaries while minimizing sensitive information in logs. Useful observability does not require retaining every private document or prompt indefinitely. Access, retention and redaction decisions apply to operational data too.
Define behavior for rate limits, timeouts, empty retrieval, provider errors and partially completed actions. Retry selectively, with limits. Provide a fallback that the organization can explain and support. A human handoff is useful only when a human actually receives the work.
Rollouts can begin with a limited group, controlled access and explicit feedback. Where appropriate, a shadow evaluation can compare results before users rely on them, subject to the same data-handling requirements. Keep a practical route to disable the feature or revert the release.
Source changes and model changes need ongoing attention. A technically available assistant may become less useful because policies changed, a connector stopped updating or a workflow moved. Monitoring should examine business usefulness alongside technical uptime.
The handoff should include architecture decisions, configurations, evaluation assets, operating procedures, source ownership and access to the systems needed to maintain the application. An internal team should be able to understand it without booking a reunion with the original consultant.
The people plan belongs inside the architecture plan.
An AI project needs more than a person who can connect a model. Depending on the scope, it may require data engineering, application development, security, domain expertise, UX research, evaluation and operational support. Some people can cover several areas. The plan should make that explicit rather than quietly assuming everyone can do everything.
My PMP and Certified ScrumMaster background, along with experience in Kaizen, RUP and Waterfall, gives me several ways to organize the work. The method should fit the uncertainty and the operating environment. Discovery may be iterative while an integration dependency requires a firm approval or release window.
I start with a clear objective and a conversation among the relevant decision-makers. Then I want a practical assessment of the assigned people: strengths, gaps, available time, dependencies and risks. A roadmap that assumes capacity nobody has is a piece of fiction with dates on it.
The architect should translate between executives, technical teams and users. Finance needs a credible investment case. Engineering needs implementable requirements. Security needs visible boundaries. Users need to understand what the system does and how to challenge it when it looks wrong.
Make the first milestones decision points.
For an initial engagement, I would expect discovery to produce a bounded use case, baseline and readiness assessment. A prototype should test the most consequential assumptions. A pilot should examine real work with controlled exposure. Production readiness should establish evidence, ownership, support and acceptable failure behavior.
The calendar depends on access to data, integration complexity, procurement, security review and team availability. A narrow prototype may move quickly. A multi-system deployment involving sensitive records may not. Neither timeline should be inferred from the length of the demo.
A project can fail while every technical task is marked complete if the users cannot fit the system into their day. Adoption work includes training, clear limitations, feedback channels and changes to the surrounding process. Leadership must also explain why the work is being introduced and what outcomes will be judged.
My project management consulting and technology and marketing project-and-talent work connect to this part of the engagement: defining the contribution, organizing delivery and making sure the organization can sustain it.
Good architectural judgment can explain the thing it chose not to build.
When assessing a proposed solution, I want to hear the alternatives and why they were rejected. What evidence justified an agent? Why this deployment model? Which data was excluded? What would cause the team to reconsider?
A strong leader can explain a failed test without blaming the user for asking a normal question. They can distinguish uncertainty from an implementation defect and bring in a specialist when the work calls for one. They can also recognize when a project’s business case no longer supports the original ambition.
I would be wary of success stories that stop at the launch. Useful evidence includes the initial condition, scope, evaluation standard, adoption, operating cost, quality outcomes and what happened after the system entered normal use. The contribution of the individual and the wider team should both be clear.
For enterprise AI, scientific rigor and creative thinking make a practical combination. One helps us establish whether the system deserves confidence. The other helps us imagine and communicate a better way to do the work. Delivery discipline connects the two to a result the business can use.
The goal is a system that helps people complete worthwhile work with appropriate control and a clear reason to keep investing. That is a substantial achievement. It does not need to pretend the model runs the company.
Questions worth answering before the next AI project.
What does an AI solutions architect do?
An AI solutions architect turns a business objective into an implementable system design, covering data, model use, retrieval, tools, integration, deployment, evaluation and operations. The role connects technical choices with measurable outcomes, access controls, costs and organizational ownership.
How is an enterprise AI consultant different from an AI developer?
An enterprise AI consultant may help select use cases, assess readiness, align decision-makers, evaluate architecture and guide delivery. A developer implements application capabilities. Responsibilities can overlap, but the engagement should specify who owns strategy, implementation, evaluation and operational support.
What is private RAG?
Private RAG usually describes retrieval-augmented generation using restricted or proprietary information. Its actual privacy depends on source permissions, application authorization, hosting, provider handling, logs and caches. The label alone does not establish that every part of the system meets the organization’s requirements.
When does an enterprise need an AI agent?
An agent may be useful when a task requires flexible planning and tool use that a predetermined workflow does not handle well. The flexibility should justify its additional complexity, with narrow permissions, validated actions, evaluation, stopping rules and appropriate human review.
Does RAG eliminate incorrect AI answers?
No. Retrieval can supply relevant evidence, but the system can retrieve the wrong source, miss context or generate an unsupported interpretation. Evaluate retrieval and answers separately, verify citations and provide a useful response when the available evidence cannot establish an answer.
Should enterprise AI run in multiple clouds?
Only when the requirements justify the added operating complexity. Existing systems, regional needs or a tested resilience strategy can provide reasons. Identity, networking, data handling, cost and fallback behavior must be evaluated across the actual deployment.
How should a company measure enterprise AI ROI?
Start with a baseline for the complete task, including verification and correction. Compare quality, time, adoption and accepted outcomes against implementation and recurring costs. Distinguish released staff capacity from realized cash savings and test the assumptions under less favorable conditions.
What should be delivered before an AI pilot moves into production?
The team should have evidence that the system meets the agreed acceptance criteria, along with defined access controls, monitoring, recovery procedures, operating costs, documentation and named owners. The appropriate requirements depend on the use case and the consequences of failure.
The leadership series
Explore the connected leadership work.
The Science and Craft of Modern Business Leadership connects the executive roles and the organization they work within.
- The Science and Craft of User Acquisition & Growth
- AI MarTech & Automation Architecture: Connecting Data to Customer Experience
- The Fractional CMO: Growth Strategy, Executive Judgment & Team Leadership
- CTO, Cloud Infrastructure & Security Leadership: Architecture, Risk & the vCISO
- Generative AI Content & Brand Strategy: Leading the Work Without Losing the Voice
- CEO Leadership: Strategy, People & Building a Company That Works
- Director of Social Media & Community: Strategy, Storytelling & Business Impact
- How a Company Should Work: Departments, Budgets, People & Shared Responsibility
Start with the work
Tell me what you want AI to make better.
You may be deciding where to begin, evaluating a proposed architecture or trying to move a promising pilot into useful daily work. My enterprise AI strategy consulting connects business objectives, data readiness, technology decisions and delivery planning.
Share the process, the people involved and the outcome you want. We can establish where I can contribute directly, where specialist support is needed and what a sensible next step looks like.
Dr. Rob Urban · Paper Boat Media · Based in Florida, working across industries and markets.
The scenarios and financial calculations in this article are illustrative. Linked primary sources provide context for retrieval, agents, evaluation, security and risk management. The recommendations describe my approach to enterprise AI decisions and delivery.