1. Why AI pilots stall
AI pilots rarely fail because the model is not clever enough. They stall when an approver asks a question the team cannot answer.
| Approver | Their question | What they need to see |
|---|---|---|
| Security | “Can it leak data or be tricked?” | Threat model, prompt-injection controls, access limits, logs |
| Legal and privacy | “What data goes where, and who can use it?” | Data-flow diagram, retention rules, no-training commitment |
| Procurement | “Are we locked in? What does it cost?” | Model portability, pricing model, exit terms |
| Accessibility and compliance | “Can everyone use it, and is it disclosed?” | Accessible chat interface, AI disclosure, records |
| Finance | “What will it cost at scale?” | Usage caps, cost per conversation, monitoring |
Answer these five before the pilot, not after it.
2. The rules in 2026
This section summarizes public rules as of October 6, 2026. It is not legal advice. Check the rules that apply to your organization.
| Rule | Status in 2026 | What it means for a typical website or service AI feature |
|---|---|---|
| EU AI Act: transparency (Article 50) | Applies from August 2, 2026 | For AI systems designed to interact directly with people, users generally must be informed that they are interacting with AI unless that is obvious in context. Some AI-generated content must be labeled. |
| EU AI Act: high-risk systems | Delayed by the Digital Omnibus (in force July 27, 2026). Most obligations for Annex III high-risk systems apply from December 2, 2027; high-risk AI in certain regulated products (Annex I) follows on August 2, 2028 | Matters if AI is used for decisions about education, employment, credit, essential services and similar areas. A support chatbot is usually not high-risk, but check your use. |
| EU AI Act: prohibited practices and general-purpose AI | In force since February 2025 and August 2025 | Applies mainly to model providers and to banned uses |
| Texas Responsible AI Governance Act (TRAIGA) | Effective January 1, 2026 | Prohibits specific harmful uses; includes disclosure requirements in specified contexts, including certain government interactions with the public |
| Colorado SB 26-189 | Enacted May 2026, repealing and reenacting the earlier AI Act; key requirements apply from January 1, 2027 | Covers automated decision-making technology used in consequential decisions (education, employment, housing, lending, insurance, health care, government services): disclosures, explanations and human review |
| Existing privacy laws (GDPR, CCPA/CPRA, state laws) | In force | Personal data typed into an AI chat is personal data. Notice, purpose and retention rules apply. |
| Accessibility (ADA, Section 508, WCAG 2.2 AA) | In force | The chat interface itself must be accessible: keyboard use, screen readers, contrast, focus |
Practical baseline for most organizations: tell users they are talking to AI, keep personal data out of model training, log conversations under a clear retention rule, make the interface accessible, and keep a person available for anything that matters.
3. Grounded answers: use your facts, not the internet
The most common AI failure in customer-facing use is a confident wrong answer. The main fix is grounding, also called retrieval-augmented generation (RAG): the AI first retrieves passages from your approved content, then answers only from those passages.
How it works
- Approved library. Your website pages, FAQs, policies, PDFs and help articles are collected into a controlled knowledge base. Nothing else is in scope.
- Retrieve. For each question, the system finds the most relevant passages.
- Answer from the passages. The model writes an answer using only those passages, and shows where the answer came from.
- Refuse when the library has no answer. “I don’t have that information; let me connect you with our team” is a correct answer.
What makes grounding work in practice
- Content quality matters more than model choice. Outdated or conflicting pages produce outdated or conflicting answers. Assign an owner to the knowledge base.
- Show sources. Citations let users and staff check answers and build trust.
- Keep the library fresh. Re-index when content changes, and remove retired pages.
- Test with real questions. Build a test set of 50 to 100 real questions with expected answers, and run it after every change.
4. Knowing when to stop: confidence and handoff
A production AI feature needs rules for when not to answer.
| Situation | What the AI should do |
|---|---|
| Strong match in the approved library | Answer, with sources |
| Weak or partial match | Ask a clarifying question |
| No match, or the question is outside scope | Say so, and offer a person |
| Sensitive topics you define (billing disputes, medical, legal, complaints, urgent safety) | Hand off to a person immediately |
| Abuse, attempts to manipulate the assistant | Refuse politely and log |
Good handoff carries the context. When a person takes over, they should see the whole conversation, so the user never repeats themselves.
Measure it. Track answer rate, handoff rate, unresolved questions and user feedback. Unanswered questions show where your content needs work.
5. Security: OWASP and agentic AI controls
The OWASP Top 10 for LLM and GenAI Applications (2025) is the most widely used list of AI-specific security risks. Here is a practical control for each.
| # | Risk | Practical control |
|---|---|---|
| 1 | Prompt injection | Treat all user input and retrieved content as untrusted; separate instructions from data; limit what the AI can do; test with known attack prompts |
| 2 | Sensitive information disclosure | Keep confidential data out of the knowledge base; redact personal data in logs; restrict who sees transcripts |
| 3 | Supply chain | Use reputable model providers and libraries; pin versions; review third-party components |
| 4 | Data and model poisoning | Control who can add content to the knowledge base; review changes |
| 5 | Improper output handling | Never execute or render AI output as code without checks; escape output in web pages |
| 6 | Excessive agency | Give the AI only the actions it needs; require human approval for anything with consequences |
| 7 | System prompt leakage | Do not put secrets or credentials in prompts |
| 8 | Vector and embedding weaknesses | Apply access control to the knowledge store; separate data per client |
| 9 | Misinformation | Ground answers, show sources, refuse when unsure (sections 3 and 4) |
| 10 | Unbounded consumption | Rate limits, message length limits and spending caps |
Agents increase the blast radius
When AI can call APIs, send messages, update records or start transactions, the question changes from “Can it say something wrong?” to “Can it do something wrong?” Before giving an AI feature the ability to act:
- Least privilege: give each agent only the tools and data it needs, with scoped, short-lived credentials
- Allowlisted tools: the agent can call only approved actions, with checked inputs
- Caps: limits on spending, transaction size and the number of actions per task
- Approval gates: a person confirms anything consequential (payments, record changes, external messages)
- Action logs: every action recorded with who, what and why
- Safe retries and rollback: repeated actions do not double-charge or double-send, and changes can be undone
6. Governance beyond technical security
OWASP tells engineering teams what can go wrong technically. The NIST AI Risk Management Framework helps the organization decide who owns those risks, how they are measured, how incidents are handled, and how governance continues after launch.
The NIST AI RMF organizes this into four functions, and its Generative AI Profile (NIST AI 600-1) adds risks specific to generative AI, such as confabulation (confident wrong answers), privacy and information security.
| NIST function | In practice for an AI feature |
|---|---|
| Govern | A named owner, written policy, approval before launch |
| Map | The use case, users, data and possible harms written down |
| Measure | The question test set, accuracy, refusal and handoff rates, cost |
| Manage | Monitoring, incident process, regular review and retirement plan |
7. Cost control: cost per successful task
AI usage is usually priced per unit of text processed (tokens). But a lower token price does not always mean a lower business cost. Measure the full cost per successful task:
Cost per successful task =
model usage (tokens)
+ retrieval and embeddings
+ tool and API calls
+ retries and agent loops
+ monitoring and logging
+ human handoff time
divided by tasks actually resolvedA cheaper model that answers wrongly more often can cost more overall, through retries, handoffs and lost trust. Costs are predictable if you design for them:
- Set budgets and caps per day and per month, with alerts before limits are reached.
- Limit message and conversation length. Long histories cost more on every turn.
- Retrieve less, but better. Sending fewer, more relevant passages lowers cost and often improves accuracy.
- Use the smallest model that meets the quality bar for each task, and reserve larger models for harder questions.
- Cache repeated answers to common questions where appropriate.
- Track cost per conversation and per resolved question, not just the monthly bill.
8. Portability: avoid lock-in to one AI provider
AI models change fast. Prices, quality and terms shift every few months. Design so you can switch.
- Put a thin layer between your application and the model provider, so changing provider is a configuration change, not a rebuild.
- Keep your knowledge base and logs in your own storage, in open formats.
- Keep your test set. It is how you prove a new model is as good as the old one before switching.
- Own the code where possible, or have a clear exit clause.
9. The procurement pack: production AI readiness checklist
Prepare these documents once, and reuse them for every approval. A one-page printable version of this checklist is available as a companion download.
Universities often send the HECVAT security questionnaire, which now includes AI questions; this pack answers most of them.
10. Contract terms that protect the buyer
Buyer protection checklist
- Data ownership, and no training on your data
- Clear retention and deletion
- Model and provider changes only with notice
- Code ownership or a usable exit
- Defined quality and handoff rules
- Incident notification terms
Sample clause: data use. “Client data, prompts and conversation records will be used only to provide the services. They will not be used to train or improve any AI model, by the Vendor or any AI provider, without the Client’s prior written consent.”
Sample clause: provider changes. “The Vendor will give the Client [30] days’ notice before changing the AI model or provider used in production, together with test results on the agreed question set.”
Sample clause: ownership and exit. “On final payment, the Client receives the source code and deployment configuration for the AI feature. The knowledge base and logs remain the Client’s property and will be exported in an open format on request.”
Sample clause: security and AI incidents. “The Vendor will notify the Client of any security incident or material AI incident affecting Client data or production behavior within the timeframe set out in Schedule [Y], and will cooperate in investigation and remediation.” The right timeframe depends on your contract and legal obligations.
Sample clause: human oversight. “The AI feature will hand off to a person for the topics listed in Schedule [X], and will not make binding commitments on the Client’s behalf.”
These are examples to discuss with your legal adviser. They are not legal advice.
11. OST’s own example: Ellie and AI-assisted engineering
Ellie, the OST AI Assistant on ost.agency
OST built and runs Ellie, the AI Assistant on its own website. It is the same product we offer to clients, so we use it every day.
| Design choice | How Ellie does it |
|---|---|
| Grounded answers | Answers from OST’s approved website content and documents, with source citations |
| Knowing when to stop | Confidence thresholds decide when to answer, clarify, refuse or hand off to a person |
| Handoff | The full conversation carries over to staff, so visitors do not repeat themselves |
| Languages | Detects the visitor’s language and replies in it, even when source content is English only |
| Measurement | Dashboards for topics, handoffs and unanswered questions, used to improve content |
| Ownership | Offered as a managed subscription or with full source-code ownership and self-hosting |
What we learned running it
- Most answer quality problems traced back to content, not the model. Fixing pages fixed answers.
- Clear handoff rules matter more than clever prompts.
- Unanswered-question reports are one of the most useful outputs: they show what visitors want that the website does not explain.
How Ellie is governed
| Control | How it is applied |
|---|---|
| AI disclosure | The chat identifies itself as an AI assistant |
| Approved knowledge only | Only OST-approved pages and documents are in the knowledge base |
| Handoff | Topics such as pricing commitments and contracts go to staff |
| Data use | Conversations are not used to train AI models |
| Provider portability | Built so the model provider can be changed by configuration |
| Review | Unanswered questions and handoffs are reviewed to improve content |
What clients usually ask us first (from OST’s AI Assistant engagements across ecommerce, nonprofit and public-sector organizations): Who can see the conversations? Can it be turned off for certain topics? What happens when it does not know? Can we host it ourselves? These questions come up consistently in our AI Assistant engagements, which is why we developed the procurement pack in this paper.
AI-assisted engineering at OST
OST uses AI coding assistants in its own development work, with every change reviewed and tested by engineers before release. Client data is not used to train AI models. AI-assisted engineering helps OST accelerate research, implementation and testing, while every production change remains subject to engineer review and QA.
12. A 90-day plan for your first production AI feature
The details for each phase are in the roadmap above; the approval step uses the procurement pack in section 9.
This is an example plan. Regulated data, complex integrations or high-risk uses take longer.
Five rules for production AI
- Ground answers in approved information. Do not rely on a model’s general knowledge for your business facts.
- Make refusal and handoff part of the design. A safe “I don’t know” is better than a confident wrong answer.
- Give agents less authority than you think they need. Use least privilege and approval gates.
- Measure cost per successful task. Token price alone is not an operating-cost strategy.
- Prepare procurement evidence before procurement asks for it. Design in security, privacy, accessibility, governance and exit terms.
Ready to move AI from pilot to production?
OST can assess your use case against security, procurement, accessibility, governance and cost requirements before you invest in a full build. We can then design and deploy a grounded production AI system with defined human oversight, measurable quality and predictable operating costs.
- See the OST AI Assistant: https://ost.agency/products/ai-assistant/
- Estimate the return with the free AI chatbot ROI calculator: https://ost.agency/tools/
- Download the one-page Production AI Readiness Checklist (companion to this paper)
- Talk to us: https://ost.agency/contact/
About the author
Manish Mittal is Technology and Digital Solutions Leader at OpenSource Technologies (OST). He has 23+ years in technology and has been with OST since 2012, and leads OST’s AI product and AI-assisted engineering work. OST is a women-led, WBENC-certified digital engineering firm with 14+ years and 500+ projects delivered for ecommerce, public sector and nonprofit clients.
Sources
All accessed October 6, 2026.
- European Union, Regulation (EU) 2024/1689 (AI Act). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Orrick, “EU AI Act Update: Digital Omnibus Finalizes 8 Compliance Changes,” July 2026. https://www.orrick.com/en/Insights/2026/07/EU-AI-Act-Update-Digital-Omnibus-Finalizes-8-Compliance-Changes
- Morgan Lewis, “EU Approves Delays and Other Amendments to Certain EU AI Act Obligations,” June 2026. https://www.morganlewis.com/pubs/2026/06/eu-approves-delays-and-other-amendments-to-certain-eu-ai-act-obligations-what-businesses-should-know
- Ropes & Gray, “Navigating TRAIGA: Texas’s New AI Compliance Framework.” https://www.ropesgray.com/en/insights/alerts/2025/06/navigating-traiga-texas-new-ai-compliance-framework
- Troutman Pepper, “Colorado Legislature Passes Bill to Repeal and Replace Colorado AI Act,” May 2026. https://www.troutmanprivacy.com/2026/05/colorado-legislature-passes-bill-to-repeal-and-replace-colorado-ai-act/
- OWASP Gen AI Security Project, “Top 10 for LLM and GenAI Applications (2025).” https://genai.owasp.org/llm-top-10/
- NIST, “AI Risk Management Framework: Generative Artificial Intelligence Profile” (NIST AI 600-1), July 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- EDUCAUSE, “Higher Education Community Vendor Assessment Toolkit (HECVAT).” https://www.educause.edu/higher-education-community-vendor-assessment-toolkit
- Colorado General Assembly, “SB26-189 Automated Decision-Making Technology.” https://leg.colorado.gov/bills/sb26-189
- Office of the Texas Attorney General, Texas Responsible AI Governance Act information. https://www.texasattorneygeneral.gov/