Generative AI Development Services: Architecture, Governance, and Delivery
Retrieval-augmented generation (RAG) is the technique most vendors point to when they promise their generative AI tool won’t hallucinate. A 2024 Stanford study put that claim to the test on leading legal AI research tools from LexisNexis and Thomson Reuters, both built on RAG, both marketed as reliable. The result: those tools still produced hallucinated or unsupported content in 17% to 33% of test queries, despite provider claims of being close to hallucination-free (Magesh et al., Stanford HAI/RegLab).
That’snot a reason to avoid generative AI. It’s the reason “architecture” can’t just mean picking RAG and calling it solved. The gap between a generative AI proof of concept and a system a business can rely on is architecture, evaluation, and governance working together, not any one of them alone. This is what that actually looks like.
What Generative AI Development Services Actually Include
The scope goes well past “connect us to GPT.” A complete engagement covers:
- Use-case scopingtoidentifywhere generationactually fits
- Architecture decisions about how the model gets its information
- The build itself
- An evaluation process that measures accuracy before launch
- Integration with your existing systems
- Governance for what happens once real users start relying on the output
Skip evaluation and governance, and you have a demo that happens to be built well. Include them, and you have something thatsurvivescontact with production traffic.
Common Generative AI Use Cases, and Where Each One Fits
Most generative AI engagements cluster around a handful of genuine use cases, and knowing which oneyou’rebuildingclarifies the architecture conversation before it starts:
- Natural-language data access: turning a plain-English question into a structured query against your own data, the pattern behindPendoah’sStatSafeengagement. This leans heavily on RAG, since the system needs current, specific facts from your actual database rather than what a model memorized in training.
- Document drafting and summarization: generating a first draft of a report, compliance narrative, or contract summary for a person to review and finish. This often combines RAG for source material with fine-tuning for a consistent house style or format.
- Customer-facing content generation: drafting responses, product descriptions, or marketing copy at volume, where consistency of tone matters more than pulling in constantly changing facts. Fine-tuning and prompt engineering usually do more of the work here than RAG.
- Code generation and technical documentation: producing code snippets, API documentation, or technical explanations, typically relying on general model capability plus prompt engineering rather than RAG or fine-tuning, since the underlying training data already covers most programming patterns well.
- Regulatory and compliance documentation: assembling and drafting the specific, defensible language regulated industries require, the pattern behind Pendoah’s GALSI engagement, which usually needs RAG for source accuracy and heavier governance given the stakes of getting it wrong.
None of these are mutually exclusive, and a single engagement often touches two or three. The point of naming them is that a vendor who can place your project in one of these categories, or explain why it doesn’t fit any of them, is thinking about your specific problem. One who jumps straight to a model recommendation before understanding which of these you’re building is not.
The Architecture Question: RAG, Fine-Tuning, or Prompt Engineering
These three approaches get lumped together constantly, and they solve different problems:
- Prompt engineering shapes how a general-purpose model responds without changing what it knows, useful for tasks thatdon’tdepend on your specific data.
- Retrieval-augmented generation (RAG)connects the model to your actual documents or database at the moment it answers, pulling in current, specific information rather than relying on what the model memorized during training.
- Fine-tuningadjusts the model’s underlying weights on your data, useful for teaching it a consistent style, format, or specialized vocabulary rather than giving it new facts to reference.
Most production systems end up combining more than one: RAG for supplying current, specific facts, fine-tuning for consistent tone or structured output format, and prompt engineering to shape the interaction on top of both.
A partner who proposes only one of the three without asking what your taskactually needsis fitting the tool to their default, not to your problem.
Consider a mid-market insurer building a tool to help underwriters answer policy questions. If the answer depends on a specific policy document that changes when policies get updated,that’sa RAG problem: the model needs to retrieve the currentdocument;not recall a memorized version that may already be outdated.
If underwriters also need every response formatted in a specific internal template with consistent terminology,that’sa fine-tuning problem layered on top. And if the interface itself needs to ask clarifying questions before answering, prompt engineering shapes thatbehavioron top of both.
A vendor who proposes a single fine-tuned model without addressing how it stays current when policies change is solving only one-third of the actual problem.
Grounding Reduces Hallucination, It Doesn’t Eliminate It
The Stanford finding from the intro is worth sitting with a little longer, becauseit’sspecific about why grounding falls short, not just that it does:
- Retrieved information can be topically relevant but factually incomplete.
- Multiple retrieved documents can conflict with each other.
- In longer contexts, models can lose track of the most relevant passage buried in the middle of what they retrieved, awell-documented failure pattern researchers call “lost in the middle.”
RAG narrows the problem considerably; the same Stanford research found general-purpose chatbots without retrieval hallucinated on 58% to 82% of legal queries, several times worse than the RAG-based tools. But narrowingisn’tthe same as solving.
What that means practically: grounding is necessary architecture, not a finished governance strategy. A vendor who treats “we use RAG” as the end of the hallucination conversation is stopping exactly where the real work starts.
How to Evaluate Output Quality Before Production
This is the step most vendor pitches skip past, and it’s the one that actually determines whether the system is trustworthy.A real evaluation process includes:
- A test set of realistic queries pulled from how the system willactually beused, not cherry-picked demo cases
- A defined accuracy benchmark specific to your use case rather than a generic industry number
- Human review of a meaningful sample before launch
- A plan for ongoing evaluation after launch, since model updates and data drift can silently change output quality over time
Ask a prospective partner to walk you through their evaluation methodology before you ask about their model choice. If theycan’tdescribe how they measured accuracy on a past project, they likely didn’t.
Governance Requirements for Generative AI in Production
Generative AI’s core risk is informational: a wrong or fabricated answer someone might act on before checking it. That’sa different risk profile than an AI agent that acts on live systems, but it still requires real governance, not an afterthought bolted on once something goes wrong publicly.
At minimum, that means:
- Clear labeling of AI-generated content
- A defined human review path for high-stakes outputs
- Logging of what was generated and what source material it drew from
- A documented process for handling a wrong or inappropriate output when a user reports one
We go deeper on what that governance actually looks like in regulated environments in our AI Compliance guide, and on the audit-trail side specifically in Layered Governance Architecture. The same human in the loop principle that applies to autonomous agents applies here too: the goalisn’tzero humaninvolvement;it’sinvolvement at the right points.
Vendor Evaluation Checklist
| Criteria | What to ask | Red flag |
| Architecture reasoning | “Why RAG, fine-tuning, or both for our specific use case?” | Defaults to one approach regardless of the task |
| Evaluationmethodology | “How do you measure accuracy before launch?” | No defined benchmark, or only demo-case testing |
| Hallucination handling | “What happens when the model doesn’t know the answer?” | Claims the system “won’t hallucinate” |
| Data handling | “Does our data train or fine-tune a model outside our control?” | Vague or default answerfavoringvendor ownership |
| Governance | “What’s logged, and what requires human review?” | Governance treated as a later add-on |
| Post-launch monitoring | “How do you catch quality drift after launch?” | No monitoring plan beyondinitialtesting |
What Generative AI Development Typically Costs
Cost varies too widely by architecture, data volume, and governance requirements to responsibly quote a single figure, and any vendor who gives you a firm number before understanding your use case is estimating as blindly as you are.
What’smore useful is understanding where the cost shows up:
- Model API costs scale with usage and are usually the smallest and most predictable line item for a well-scoped system.
- RAG implementation costs come from building and maintaining the retrieval pipeline, indexing your documents, keeping the index current as your data changes, and tuning retrieval quality work that’s ongoing, not a one-time build.
- Fine-tuning costs come from data preparation and training compute, typically a larger upfront cost than RAG but a smaller ongoing one, since a fine-tuned model doesn’t need constant re-indexing.
- Evaluation and governance are the costs most proposals underestimate: building a real test set, running human review cycles, and setting up monitoring all take real time from real people, not just compute.
The honest budgeting conversationisn’t”how much does generative AI cost.”It’s”how much does each of these categories cost for our specific architecture and data,” and a partner who can break that down before the contract is signed is a different bet than one who quotes a single number upfront.
Where Pendoah Fits
Two of Pendoah’s own case studies are generative AI systems in production, not prototypes.
StatSafe translates plain-English questions into database queries for pharmaceutical and life sciences clients, holding a 92% query accuracy rate specifically because the evaluation methodology was built in from the start, not measured only after complaints started.
GALSI drafts fundraising and regulatory documentation for life sciences startups, going from concept to a production-ready, multi-tenant platform in8 weekswith 75% faster documentation cycles, a timeline that was held specifically because architecture and governance were part of the build from day one rather than a phase added afterward.
Ifyou’rescoping this kind of work, Pendoah’s Custom AI Development services are built around that same sequence: architecture decisions grounded in the actual task, evaluation beforelaunching, and governance thatdoesn’tget added after the fact.
Key Questions to Ask Before You Sign
- Does the proposal explain why a specific architecture, RAG, fine-tuning, or both, fits our use case, or does it default to one approach?
- What does the evaluation process look like before this goes live, andwhat’sthe accuracy benchmark?
- What happens when the modeldoesn’thave a confident answer? Does it say so, or guess?
- What’slogged, and who reviews outputs before they reach a customer or decision-maker?
- Who owns the resulting model, fine-tuned weights, and any data used to train them?
The Bottom Line
Generative AI development services aren’t just a model and a prompt. The architecture decision, RAG, fine-tuning, or both, determines what the system can know. The evaluation process determines whether you can trust what it says. And governance determines what happens whenit’swrong.
A partner who leads with the model they’ll use, before asking what evaluation and governance your use case requires, is optimizing for a fast pitch, not a system that survives production.
Ready to scope a generative AI project with the architecture and evaluation work built in from the start? Book a consultation with Pendoah, or look through our case studies to see how this played out for other clients.
