Services / How we work

How AI Services Work

From problem definition to integration, support, and long-term improvement.

Custom AI work should not begin with a random feature request or a generic chatbot template. It should begin with the real situation: the workflow, users, data, systems, constraints, risks, and result the client needs.

inAi Services follows a practical path: understand the problem, define the scope, design the system, build and evaluate the solution, integrate it into the right environment, and support it after delivery where agreed. The exact shape depends on the project, but the working principle stays the same: the client should know what is being built, what is included, what information is needed, what remains private, how the solution will be operated, and what happens after launch.

Start a Services conversation Explore AI Services

AI projects need more than a model call.

Many AI projects fail because the first version is treated as the whole solution. A chatbot is built before the knowledge base is cleaned. A prototype is shown before anyone defines how success will be judged. A workflow is automated before the exceptions are understood. A model is connected to data before the data is structured, reviewed, or bounded.

Useful AI systems usually need conventional product and software work around the AI layer: data preparation, user experience, access control, integration, logging, evaluation, error handling, review points, deployment, cost management, and support. The model matters, but the system around the model often determines whether the result is useful in practice.

That is why inAi treats Services as implementation work, not only advisory work. The goal is not to recommend AI in the abstract. The goal is to define, build, integrate, and support a system that can work in the client’s real context.

Discovery

Scope

Confidentiality

Data and access

Ownership and handover

Solution design

Build and evaluation

Infrastructure and operation

Delivery and corrections

Ongoing support

Pricing

Boundaries

Start with the problem, not the architecture.

A client does not need to arrive with a complete technical specification. In many cases, the first useful step is to describe the problem clearly: what is slow, manual, expensive, confusing, repetitive, risky, difficult to scale, or blocked by existing tools.

The first conversation is used to understand the situation and decide whether AI Services is the right path. Some problems may fit an existing inAi product. Some may need a small prototype. Some may need a deeper discovery phase before a build is realistic. Some may not be good AI problems at all, or may require conventional software, data cleanup, process redesign, or specialist legal/security review before AI should be added.

A good Services project begins when the problem, context, and desired result are concrete enough to define a next step.

Discovery: understand the real situation.

Discovery is where inAi and the client make the problem specific enough to solve. The work may include reviewing the current workflow, understanding who will use the system, identifying the data or documents involved, mapping the tools or platforms that need to be connected, and clarifying what the client expects the AI system to produce.

For a product integration, discovery may focus on the existing product flow, user experience, APIs, data model, and where AI should or should not appear. For an internal knowledge assistant, it may focus on document sources, access boundaries, update frequency, source references, and answer quality. For a data-analysis layer, it may focus on data condition, schemas, dashboards, exports, reporting needs, and what decisions the analysis should support. For an agentic workflow, it may focus on steps, tools, permissions, review points, recovery paths, and failure modes.

The output of discovery should not be a vague enthusiasm for AI. It should be a clearer definition of the work: what problem is being solved, what materials or systems are involved, what constraints matter, what success looks like, and what should happen next.

Discovery may clarify

01the current workflow and the people involved;

02the data, documents, tools, APIs, or systems required;

03what should be automated, assisted, reviewed, or left manual;

04what output quality means in this specific context;

05what permissions, approvals, or human review points are needed;

06what cannot be promised until data or systems are reviewed;

07whether the next step should be an audit, prototype, fixed-scope build, integration, or longer-term support relationship.

Scope comes before development.

After discovery, the project should be translated into an agreed scope before development begins. Scope protects both sides. It tells the client what inAi is building, what is included, what is not included, what access or materials are needed, how the work will be evaluated, and what kind of support or handover is expected.

AI projects can change once real data, documents, users, or edge cases are inspected. That is normal. The important point is that changes should be handled explicitly. If a project expands into new features, new data sources, new integrations, larger scale, different infrastructure, or a broader workflow than originally agreed, that should be treated as a scope change, not silently absorbed into the first proposal.

This is how custom work stays healthy. The client gets clarity. inAi gets the conditions needed to deliver properly. Both sides can separate corrections inside the agreed scope from new work that should be planned, priced, and scheduled separately.

Scope should define

01the problem being solved;

02the expected deliverables;

03what is included and excluded;

04the data, documents, accounts, APIs, or systems required;

05the expected integration points;

06the evaluation or acceptance criteria;

07the delivery format;

08the support or handover model;

09the pricing model and known cost factors;

10what counts as correction, and what counts as new work.

Confidential by default.

Client work is confidential by default. Services projects may involve private documents, product plans, operational processes, business data, internal tools, users, datasets, source materials, or unreleased product ideas. inAi does not treat those materials as public proof.

We do not publish client names, project details, screenshots, results, outputs, testimonials, datasets, documents, or case studies unless the client agrees. Some clients may later choose to be public references or case studies. That is optional. The default is privacy.

Confidentiality also means that public examples on the Services page are scenario examples, not claims about specific clients. A document-processing workflow, internal assistant, AI data-analysis layer, product integration, prototype, or agentic workflow can be described as a possible project type without exposing who inAi works with or what was built for them.

Clear with the client. Private to everyone else.

Confidentiality does not mean the project should be unclear to the client. The client should understand what is being built, what data or systems are used, how the solution is expected to work, where the important limitations are, what costs may appear, and what happens after delivery.

A Services project should be transparent inside the client relationship and private outside it. inAi can explain tradeoffs, limits, infrastructure choices, model/API considerations, support needs, and operational assumptions to the client without turning the project into a public case study.

Ownership and handover are agreed before work begins.

Ownership should be defined project by project. Custom AI work can involve several different layers: client data, confidential business context, documents, workflows, prompts, application code, integrations, UI, deployment scripts, model/API configuration, documentation, reusable components, and inAi pre-existing methods or technology.

For that reason, the public rule is not “one model fits all.” Ownership of deliverables, source-code access, licensing, reuse rights, handover terms, and ongoing maintenance responsibilities should be agreed before development begins.

Client-specific data, private documents, confidential business context, internal workflows, and client-provided materials remain client-confidential. General methods, reusable patterns, inAi pre-existing technology, and components not specific to the client are handled according to the project agreement.

Use the minimum useful access.

AI systems often need access to documents, databases, product information, application data, files, APIs, or internal tools. That access should be practical and bounded. The goal is to use the minimum useful access needed to solve the problem, not to collect more information than the project requires.

Before work begins, inAi and the client should clarify what data or systems are needed, who can authorize access, what should not be shared, how sensitive materials should be handled, and what the client must review or approve. In some projects, the client may provide sample data or synthetic examples first. In others, real data may be required to evaluate whether the system can work.

The right access model depends on the project. A prototype may need limited test data. A production integration may need authenticated APIs, deployment credentials, staging environments, or approved document sources. A private knowledge system may need clear boundaries around what the assistant is allowed to search. These choices should be made deliberately, not assumed.

Data and access may include

01approved document sources;

02databases, exports, spreadsheets, or product data;

03APIs and integration credentials;

04staging or test environments;

05sample data, anonymized data, or synthetic data where appropriate;

06access rules for different users or teams;

07review responsibilities for sensitive or uncertain outputs;

08boundaries around what the system must not use.

Design the right system shape.

Not every AI problem needs the same architecture. A useful solution might be a private assistant, retrieval system, product feature, document-processing pipeline, AI-assisted dashboard, data workflow, agentic process, prototype, custom application, or a combination of several parts.

Solution design is where inAi chooses the system shape around the problem. That may include model/API choices, retrieval or search design, data pipelines, prompts and instructions, UI behavior, permission logic, review points, integration surfaces, output formats, logging, deployment path, and support model.

This step matters because AI should not be added as decoration. The design should answer practical questions: where the AI appears, what it is allowed to do, what it should produce, how users inspect or correct it, how it connects to existing tools, and what happens when the system is uncertain or wrong.

Build, test, and evaluate against real use.

A working AI system should be tested against the kind of cases it will actually face. That does not mean every possible future case can be predicted. It means the project should include evaluation that is specific enough to expose obvious weaknesses before delivery.

Depending on the project, evaluation may include sample prompts, test documents, expected outputs, comparison cases, review by client experts, failure-mode checks, uncertainty flags, source references, structured data validation, integration tests, user feedback, or repeated runs over representative examples.

The purpose of evaluation is not to pretend that AI is perfect. The purpose is to understand how the system behaves, where it is strong, where it needs review, and what conditions must be respected for the solution to be useful.

The client should not have to manage the AI stack alone.

A custom AI solution may require hosting, storage, AI provider access, API keys, authentication, databases, job queues, monitoring, logs, backups, deployment pipelines, user access, or connections to the client’s existing tools. The client should not have to understand or manage all of that alone.

Depending on the project, the solution can run on infrastructure arranged by inAi, infrastructure controlled by the client, or a hybrid setup. The right model depends on data sensitivity, client preferences, existing systems, deployment needs, budget, technical ownership, and long-term support expectations.

Hosting, storage, model/API usage, third-party service costs, monitoring, maintenance, backups, uptime expectations, and support responsibilities should be defined in the proposal or support arrangement. inAi’s role is to organize the technical route needed for the solution to work, not to imply that every project uses inAi-owned hardware or one fixed hosting model.

inAi-arranged setup

inAi helps arrange and operate the technical setup where that is the right path for the project and support model.

Client-controlled setup

The solution runs in infrastructure controlled by the client, with inAi building, integrating, documenting, or supporting according to the agreement.

Hybrid setup

Some parts are managed or arranged by inAi, while other parts remain inside the client’s own systems, accounts, cloud environment, or internal tools.

Delivery should include a clear correction window.

Delivery is not just sending files or turning on an integration. A project should define what acceptance means: what has been delivered, what the client can test, what conditions apply, what issues count as corrections inside the agreed scope, and how long the testing or acceptance period lasts.

During the agreed testing and acceptance period, inAi corrects issues related to the agreed scope so the delivered system works as intended under the conditions defined for the project. This is different from open-ended redesign. If the system does not meet the agreed delivery criteria, that is a correction issue. If the client wants new features, new integrations, different workflows, broader scale, additional data sources, changed behavior, or a new product direction, that is additional work.

This distinction should be clear before work begins. It protects quality without turning the project into an unlimited change process.

Area

Products

Services

Corrections

issues inside the agreed scope, during the agreed testing or acceptance period.

Change requests

new features, new workflows, additional integrations, larger scale, new data sources, changed requirements, or later product evolution.

AI systems often evolve after the first version.

A first working system often reveals the next layer of needs. Users ask for a new output format. A team wants another data source connected. The workflow changes. A model/provider changes. The client wants the system to support more users, more documents, more products, more languages, more integrations, or a more complex approval process.

That evolution can be valuable, but it should be managed deliberately. New requirements should be treated as change requests, follow-up phases, or ongoing support and development work. This keeps the original delivery clean while leaving room for the system to improve over time.

The goal is not to freeze the project forever. The goal is to separate delivery from evolution so the client knows what is included now and what should be planned next.

Support can continue after launch.

AI systems do not always remain stable forever just because the first version works. Data changes. Users find edge cases. Models and providers evolve. APIs change. Costs shift. Workflows expand. A system that is useful today may need maintenance, monitoring, updates, bug fixes, prompt or retrieval improvements, model/provider changes, UI changes, new integrations, or additional evaluation later.

inAi does not position Services as “build once and disappear.” A project can include handover only, limited post-launch support, or an ongoing monthly support and development relationship. The right model depends on the importance of the system, how often it is used, how much it depends on external providers, how much client data changes, and whether the client wants inAi to remain responsible for maintenance and improvement.

Ongoing support should be agreed explicitly. It can include maintenance, monitoring, updates, bug fixes, provider/model adjustments, workflow improvements, new feature development, user feedback cycles, documentation updates, and periodic review of system quality.

Handover

The project is delivered with documentation and the client takes responsibility after the agreed acceptance period.

Limited post-launch support

inAi remains available for a defined support period after delivery to correct scoped issues and support adoption.

Ongoing support and development

inAi continues to maintain, monitor, improve, and extend the system under a separate monthly or project-based arrangement.

Pricing depends on scope, responsibility, and operating needs.

AI Services are priced by project because custom AI work can vary widely. A short discovery phase, a focused prototype, a product integration, a document-processing workflow, a data-analysis layer, and a long-term supported system do not have the same cost structure or responsibility.

Pricing may depend on discovery needs, project complexity, data condition, data preparation, number of integrations, deployment model, hosting or infrastructure requirements, model/API usage, third-party service costs, hardware or compute needs where relevant, evaluation depth, support expectations, and the level of ongoing responsibility after launch.

For that reason, inAi does not need to publish fixed service prices for every possible situation. The right pricing comes after the problem, scope, technical requirements, support model, and operating costs are understood.

Discovery or AI implementation audit

A focused phase to understand the problem, data, workflow, risks, and possible solution path.

Prototype or MVP

A limited build used to test whether an AI idea, assistant, workflow, or product feature can work before committing to a larger system.

Fixed-scope build

A defined project with agreed deliverables, acceptance criteria, correction window, and handover or support plan.

Integration project

A project focused on adding AI into an existing product, website, internal tool, database, CRM, ERP, CMS, PIM, marketplace, or workflow system.

Ongoing support

Maintenance, monitoring, improvements, bug fixes, model/provider updates, workflow changes, and support after delivery.

Retained development

A longer-term relationship for clients who want inAi to continue developing and improving an AI system over time.

The client brings context. inAi builds the technical path.

A Services project works best when both sides have clear responsibilities. The client does not need to manage the AI stack alone, but the client’s context is essential. inAi cannot design a useful system without understanding the workflow, users, goals, constraints, data, and practical reality of the organization or project.

The client usually needs to provide business context, access to relevant materials or systems, feedback on outputs, timely approvals, and people who can validate whether the system is useful. inAi can provide the AI-native product thinking, system design, implementation, integration, evaluation, deployment path, documentation, and support where agreed.

The best projects are not built from vague AI ambition. They are built from a real problem, clear client knowledge, and a technical path that can be tested against actual use.

Custom AI work starts with clear commitments.

A serious AI project should not begin with vague promises. Before inAi confirms scope, timeline, cost, automation level, or long-term support, we first review the real problem: the workflow, available data, existing systems, users, risks, constraints, and expected outcome.

That review helps define what can be built, what should be tested, what requires specialist review, what needs human approval, and what success should mean. It also protects the client from receiving a fragile AI demo that works once but cannot operate reliably inside the real situation.

The goal is not to make the offer weaker. The goal is to make the project concrete enough to deliver, support, and improve.

What we clarify before work begins

01Scope and success criteria

02Data condition and access

03Existing systems and integrations

04Model, API, hosting, or compute costs

05Legal, security, or domain-specific review

06Automation level and human review points

07Delivery, testing, and correction period

08Ownership, handover, and source-code access

09Ongoing support and future changes

10Public references only with client consent

Where Services fits inside inAi.

Services are part of inAi’s broader mission to bring AI to the real world, but they have a specific role.

Products are what inAi builds for repeatable needs. Business Products, Consumer Products, and Products for Agents are inAi-owned product directions. Open Source is selected public technology released for builders and the wider ecosystem. Services are different: they are custom projects built around a client’s own product, workflow, data, infrastructure, constraints, and goals.

This distinction matters. Services should not reduce inAi to a generic agency, and products should not pretend to solve every client-specific problem. Some needs are best served by an inAi product. Some are best served by a custom Services project. Some Services work may later reveal a repeatable product opportunity, but the public path stays clear: specific client problem, custom AI work, agreed scope, private by default.

Bring the real problem.

A useful Services conversation starts with the situation: what is not working, what the client wants to improve, what data or systems are involved, who will use the result, what risks or constraints matter, and what would make the project successful.

From there, inAi can help decide the right path: discovery, prototype, fixed-scope build, integration, handover, ongoing support, or retained development.

Start a Services conversation Explore AI Services

Loading page content...