Apply for AI Grants India

AI architecture baselines are the minimum technical and operational standards an AI system must meet before it moves from an experiment into a dependable product. They are not a single reference architecture or a preferred cloud stack. They are a documented set of decisions, controls, and measurable thresholds that make AI delivery repeatable across teams.

For an India-based startup, this matters when a prototype must handle real users, sensitive data, variable connectivity, and strict cost constraints. A good baseline helps a small team avoid rebuilding the same foundations for every feature while leaving room for use-case-specific choices.

What an AI architecture baseline should cover

A useful baseline spans the full lifecycle, from data collection to production monitoring:

• Data: Sources, ownership, quality checks, consent, retention, lineage, and access controls.
• Models: Approved model classes, evaluation datasets, versioning, fallback behaviour, and release gates.
• Application layer: APIs, orchestration, prompt or policy management, caching, and user-facing safeguards.
• Infrastructure: Compute, storage, networking, observability, deployment environments, and disaster recovery.
• Security and governance: Identity, secrets, encryption, audit logs, privacy controls, and incident response.
• Operations: Monitoring, cost controls, rollback procedures, support ownership, and periodic review.

The baseline should state what is mandatory, what is recommended, and what requires an exception. Without this distinction, architecture documents become wish lists that teams quietly bypass.

Start with workload classification

Do not apply the same architecture to every AI workload. First classify the product by its risk, latency, data sensitivity, and scale requirements. A customer-support summariser, a medical triage assistant, and a fraud-detection pipeline need different controls even if all use machine learning.

Record at least these attributes:

• Interaction pattern: Batch, asynchronous, streaming, or real-time request-response.
• Latency target: For example, p95 response time rather than an average that hides slow requests.
• Availability target: Expected uptime, recovery point objective, and recovery time objective.
• Data sensitivity: Public, internal, personal, financial, health, or regulated data.
• Failure impact: Whether an incorrect output is inconvenient, expensive, unsafe, or legally significant.
• Scale profile: Requests per second, dataset size, peak traffic, and geographic distribution.

This classification determines whether you need a GPU-serving layer, asynchronous queues, human review, regional data controls, or a simpler managed API. Teams building conversational products can compare these choices with the architecture patterns in realtime GPT models, while voice products may need additional streaming and interruption handling covered in this voice-agent architecture guide.

Define the data baseline

Data quality is an architectural concern, not only a data-science task. Your baseline should define how data enters the system, who can use it, and how it is removed or corrected.

Specify:

• A data catalogue with source, owner, purpose, schema, sensitivity, and retention period.
• Validation for missing values, duplicates, outliers, schema drift, language coverage, and label quality.
• Separate development, staging, and production datasets, with controlled access to sensitive records.
• Reproducible preprocessing pipelines so training and inference apply compatible transformations.
• Consent, deletion, correction, and retention workflows aligned with applicable Indian privacy obligations.
• Dataset and feature versions linked to every model release.

For multilingual or India-focused products, test representation across languages, scripts, accents, regions, and device conditions. A model that performs well on English benchmark data may fail on Indian language queries, code-switching, or low-bandwidth inputs.

Set model and evaluation gates

The baseline should prevent a model from reaching production solely because it performs well on one offline metric. Define an evaluation contract before selecting a model.

Include:

• Task-specific quality metrics, such as precision, recall, calibration, groundedness, or word error rate.
• Slice-based testing by language, geography, customer segment, device, and difficult input type.
• Safety tests for prompt injection, data leakage, harmful outputs, hallucination, and unauthorised actions.
• A comparison against a simple baseline, such as rules, retrieval, or a smaller model.
• Latency, throughput, memory, token, and cost limits.
• Human review criteria for high-impact decisions and low-confidence outputs.

For systems using retrieval-augmented generation, evaluate retrieval separately from generation. For agents, test tool selection, permissions, retries, timeouts, and termination—not just the final answer. A memory layer can improve continuity, but it also introduces retention and privacy risks; the design considerations in AI system memory for personalised LLMs are useful when defining those controls.

Establish a production reference pattern

A practical baseline commonly includes:

1. Client and API gateway for authentication, rate limits, request validation, and correlation IDs.
2. Orchestration service for prompts, model routing, retrieval, tool calls, and policy checks.
3. Model gateway that standardises provider access, timeouts, fallbacks, usage tracking, and redaction.
4. Data and retrieval layer containing approved stores, indexes, metadata, and access-aware retrieval.
5. Asynchronous workers for long-running jobs such as document processing, fine-tuning, and batch scoring.
6. Observability stack for logs, traces, quality signals, cost, latency, and error rates.
7. Evaluation and release pipeline that blocks deployment when required tests fail.

Keep interfaces stable even when model providers change. A model gateway and clear domain APIs reduce lock-in and make it easier to compare hosted, open-weight, and self-hosted options. Caching can lower latency and cost, but it must respect tenant boundaries and freshness requirements; see AI cache backend patterns for implementation considerations.

Security and governance controls

Security should be designed into the baseline rather than added after the first incident. Require least-privilege identities, secret management, encryption in transit and at rest, dependency scanning, network segmentation, and immutable audit logs.

For AI-specific threats, add controls for:

• Prompt injection and untrusted instructions in retrieved documents.
• Sensitive information appearing in prompts, logs, traces, or model outputs.
• Tool calls that exceed the user’s authorisation.
• Model and dataset tampering across the supply chain.
• Cross-tenant data exposure in caches, vector stores, and conversation memory.
• Unapproved model changes or silent provider substitutions.

Use policy enforcement at the tool and data-access layers, not only in prompts. High-risk actions should require explicit confirmation, transaction limits, or human approval. For search-heavy products, a secure design such as federated search for startups provides a useful model for isolating sources and permissions.

Reliability, cost, and observability

Define service-level objectives for both infrastructure and AI quality. Monitor p50 and p95 latency, error and timeout rates, queue depth, token or GPU usage, cache hit rate, retrieval quality, refusal rate, and user corrections. Track costs by product, tenant, model, and workflow so an apparently successful feature cannot hide an unsustainable bill.

Every production request should be traceable through a correlation ID without exposing unnecessary personal data. Store enough information to reproduce failures: model version, prompt or template version, retrieved-source identifiers, tool calls, configuration, and outcome. Apply redaction and retention rules before enabling verbose logging.

Design graceful degradation from the start. A service might switch to a smaller model, return a cited search result, queue the task, or route the case to a human when the primary model or provider is unavailable. Test these paths with fault injection rather than assuming they work.

Baseline documentation and review

Keep a short architecture decision record alongside the code. It should include the workload classification, data flows, trust boundaries, component owners, SLOs, evaluation gates, known limitations, and exception expiry dates. A diagram is useful, but a decision without an owner or measurable acceptance criterion is not a control.

Review the baseline at least quarterly and after major changes in model providers, data sources, regulations, traffic, or risk profile. Version the baseline like software: require review, record changes, and make rollback possible. Distributed teams can also use the documentation practices described for event-driven Python architectures to keep system knowledge close to implementation.

A practical adoption checklist

Start small and make the baseline enforceable:

• Classify the first workload and define its users, data, risks, and SLOs.
• Write mandatory controls for identity, secrets, logging, evaluation, and rollback.
• Create a representative evaluation set, including Indian languages or operating conditions where relevant.
• Build one paved-road deployment template with approved integrations.
• Add automated quality, security, and cost checks to CI/CD.
• Run a production pilot with explicit alert thresholds and an incident owner.
• Review actual failures and costs, then update the baseline rather than adding ad hoc fixes.

The strongest AI architecture baseline is not the most elaborate one. It is the smallest set of standards that reliably protects users, controls cost, and helps builders ship faster. As of 2026, model capabilities are changing faster than most engineering teams can rewrite their platforms, so stable interfaces, measurable evaluation, and disciplined governance are more valuable than committing to a single model or vendor.