AI, ML & agentic AI FAQs

We build three things: custom machine learning models for predictive analytics, computer vision and anomaly detection; secure generative AI and RAG architectures grounded in your own data; and agentic workflows that automate multi-step enterprise decisions. We also build the data pipeline engineering underneath these, using tools like Apache Spark, Airflow and BigQuery to feed them reliably.

Bitkosh deploys secure, isolated AI architectures rather than routing your data through shared public services. Your proprietary data is never used to train public models, and our architectures are designed with enterprise compliance frameworks such as ISO 27001 in mind, so sensitive information stays inside your own environment throughout development and deployment.

Yes. We build custom APIs and microservices around your existing systems so intelligent features, such as a RAG-grounded copilot or a predictive model, integrate directly into your current web, mobile or enterprise application. You do not need to rebuild your stack; the AI layer sits alongside what you already run and connects through defined interfaces.

Off-the-shelf AI tools are not grounded in your business data, so they can hallucinate or, worse, surface information they should not have access to. We build retrieval-augmented generation architectures that are strictly grounded in your enterprise data layer, so answers come from your actual records rather than the model's general training.

A chatbot summarises and talks. An agent takes action: it reads your systems, calls tools such as your database, API or mail server, and executes steps like filing a ticket or issuing a refund. Because acting has real consequences, we build in checkpoints where the agent pauses and waits for a human before anything costly happens.

We design the guardrails before writing a single prompt: what the agent may touch, which actions require human approval, what data it can retain, and what it must never do. High-stakes actions pause for a human to approve, and every step, correct or not, is written to an audit trail so you can see what happened and why.

We look at the work your team repeats every day and check whether an agent genuinely adds value over a simpler fix. Some requests are really just a scheduled script dressed up as AI, and we will tell you that rather than build something unnecessarily complex. Agents are reserved for tasks that need judgement across multiple steps and tools.

Yes. We build an evaluation test set from your own historical cases and measure the agent against it, so improvement is a number you can check after every change rather than a feeling. Every deployed agent also produces an audit log of each action and decision that your team can review afterward.

No. Every agent gets governed, scoped access to specific tools, such as your order database or mail system, agreed before development starts. Actions above an agreed risk threshold require human approval, and permissions are configured to match your existing roles, so the agent can only do what it has explicitly been allowed to do.

We deploy agents with logging, cost controls and an effort ceiling built in, so an agent that gets stuck in a loop or hits an unusual case stops itself instead of continuing to run and racking up model or API charges. Finance teams get visibility into where those cost ceilings sit and where any savings actually land.

Yes. Source code is handed over along with the working agent, its tool integrations, approval and escalation rules, and a runbook so your own team can operate and extend it afterward. You are not locked into us for every future change; the handover is built into the delivery, not offered as an afterthought.

Operations leads whose teams repeat the task the agent will take over, engineering leads accountable for what the agent is allowed to touch, compliance and legal for data handling and DPDP obligations, and finance for cost ceilings and where the resulting savings land. Leaving any of these out tends to surface as a problem after launch.

Yes, if you have deployed an LLM copilot, RAG pipeline or autonomous agent. Prompt injection is one of the core risks in the OWASP Top 10 for LLM Applications, and we run adversarial testing against both direct and indirect injection attempts to see whether an attacker can push the model into ignoring its instructions or taking unintended actions.

We run a model supply chain review before any third-party or open-weight model goes into production, checking its provenance and integrity rather than assuming the source is trustworthy. This sits alongside our other AI security work, such as prompt injection testing and data leakage checks, so the model itself is assessed, not just the application around it.

It can, if access control is not built into the retrieval layer. We review RAG and data pipeline permissions specifically so a query from one user can never surface data that user is not entitled to see, which is a different check from standard application access control since retrieval can pull from many underlying sources at once.

That is one of the specific things we test for. Our data leakage prevention work checks whether a model can be coaxed, through crafted prompts or edge-case queries, into revealing its training data, its system prompt, or information belonging to another tenant sharing the same deployment. It is tested rather than assumed safe.

We agree the scope with you before testing starts, and most engagements run against a staging or sandboxed instance rather than the live model, so testing never risks real user traffic or production data. If a production test is genuinely required, that is scoped and agreed explicitly rather than assumed.

We treat tool-calling as the actual attack surface for agentic systems, reviewing the permissions and guardrails an agent has over each connected tool so it cannot be manipulated, through a crafted input or an unexpected chain of steps, into taking an action outside what it was scoped to do.

We map your AI systems against emerging AI regulation and your internal responsible-AI policy, producing the documentation and control mapping needed to show what each system does, what data it touches, and how it is governed. This sits alongside a statement of work, technical findings and a risk-rated remediation register from the wider engagement.

For agentic workflows we build on frameworks like LangChain and CrewAI. For the data layer underneath, we use Apache Spark, Airflow and BigQuery to build scalable ETL pipelines, secure data lakes and fast warehousing, so the machine learning models and RAG systems on top have reliable, well-structured data to draw from.

Yes. Our custom ML work includes models trained for predictive analytics, computer vision, and anomaly detection, built specifically around your data rather than adapted from a generic template. These sit inside the same applied AI practice as our generative AI, RAG, and agentic workflow work, so a vision or anomaly-detection model can plug into a larger pipeline or agent if your use case calls for it.

RAG, or retrieval-augmented generation, grounds an LLM's answers in your actual enterprise data instead of letting it guess from general training data. It needs a dedicated architecture because the retrieval layer has to be secure and tightly scoped, so the model only ever pulls from data the requesting user is actually allowed to see, rather than searching everything indiscriminately.

Sometimes, and we say so. Part of our process is looking at what your team actually repeats and admitting when a request is really a cron job wearing a costume rather than something that needs an autonomous agent. True agentic AI is reserved for work where an agent reads systems, takes actions through governed tools, and knows when to stop for a human, which a simple script cannot do.

The agent pauses that specific action and waits, rather than guessing or proceeding anyway. Earlier and later steps in the workflow can still complete on their own, but the step requiring sign-off holds until a person approves it, and that approval is recorded as part of the audit trail before the agent continues.

A single-purpose agent handles one narrow task with a small, fixed tool set, which is where most projects should start. A stateful multi-step agent tracks context across a longer sequence of actions and decisions, which is only worth building once real cases show a single-purpose agent or structured workflow genuinely cannot handle the job.

Traditional application penetration testing does not cover prompt injection, model behavior, or RAG data-access boundaries, so it can miss the risks specific to an LLM layer entirely. Our AI/LLM security service tests that layer directly, on top of standard application security, covering things like jailbreak attempts, tool-calling permissions, and whether a model can be coaxed into leaking data it shouldn't reveal.

These reviews are built around CISOs and security leadership, IT and engineering teams who own the systems being tested, risk and compliance or procurement teams, and, for public-sector work, government or regulated program owners. Involving the right mix up front makes it easier to agree scope and act on findings afterward.

It matters because a model's origin determines whether you can trust what it will actually do once it is running in your systems. Our model supply chain review is a provenance and integrity check on third-party and open-weight models before they go into production, confirming where a model came from and whether it has been tampered with, since an unverified origin can carry hidden behavior that only surfaces once it is already serving your users.

Yes, data handling and DPDP obligations are treated as a core stakeholder concern in our agentic AI work, alongside compliance and legal teams. Our AI governance and compliance service also maps your AI systems, including RAG pipelines and agents, against emerging regulation and your own internal responsible-AI policy, producing documentation your compliance team can actually use.

We find the work actually worth automating, then design the guardrails, which is deciding what the agent may touch, what needs approval, and what it must never do, before any prompt is written. From there we build the thinnest version that works, evaluate it against real historical cases, and ship it into your environment with logging and cost controls so it can be watched after launch.

Yes, this is effectively how we start every project. Rather than jumping to a stateful multi-step build, we build the thinnest single agent with a small tool set and run it against real cases first, which is also offered as its own productized engagement, the Agent Feasibility Sprint, before you commit to a larger structured workflow or multi-step build.

Yes. The evaluation test set built from your historical cases is one of the project outputs you receive, along with the source code, tool integrations, and audit logging. That means you can keep measuring the agent against the same benchmark after handover, rather than relying on us to tell you it still performs well.

An effort ceiling is a limit built into the deployed agent so that if it gets stuck or starts looping on a task, it stops instead of continuing to run and racking up cost. It works alongside logging and other cost controls that are put in place at the point an agent ships into your environment, not added afterward as an afterthought.

Generic AI tools are built for a broad audience and often were not designed with your specific data-handling requirements in mind, which is part of why they can hallucinate or handle proprietary data in ways that violate privacy expectations. We build isolated AI architectures instead, where your proprietary data is never used to train public models.

It means the agent only has permissioned, scoped access to the specific tools and systems it needs for its task, rather than broad standing access to everything. This access is one of the guardrails agreed before any prompt is written, and it is reviewed as part of the tool integrations delivered when the agent is handed over.

Data silos and manual, repetitive workflows are the main problems we target, since they consistently trap value that should be available for operational decisions. We build ETL pipelines, secure data lakes, and warehousing solutions using tools like Apache Spark, Airflow, and BigQuery, so data actually flows to where your team or your AI models can use it.

It can take that kind of action, such as filing a ticket, revoking access, or issuing a refund, but the design decides in advance which of those actions need a human to approve first. An agent that only summarizes is low risk, but one that acts on your systems is a different engineering problem precisely because getting it wrong has a real cost.

It is enough for an initial, practical read on whether AI is the right fit, not a full commitment. The 30-minute session with our engineering team is meant to produce a clear plan with no obligation attached, and deeper questions like architecture and guardrail design are worked out in the discovery and architecture stages that follow if you proceed.

Before any testing begins, we baseline the mission: confirming authority to test, scope boundaries, data classification, stakeholders, critical assets, and the acceptance criteria that define success. This scoping step is what determines whether an engagement tests a staging environment or production, and it is agreed with you up front rather than decided once testing is underway.

It means an agent we build isn't tied to one AI provider. The tool access, guardrails, and approval steps are engineered around your workflow, not around a specific model's API, so the underlying model can be changed later without rebuilding the agent from scratch or renegotiating how it is allowed to act.

Every step the agent takes gets logged as a discrete entry, for example an order being located, an action pausing for approval, who approved it, and each downstream step it triggers like sending an email or closing a case. The result is a complete, ordered record of what the agent did and who signed off on each step.

For multi-agent, autonomous systems we build on LangChain and CrewAI, using them to orchestrate several agents working together on complex enterprise decision-making rather than a single model handling everything. The choice of framework is part of the architecture phase and depends on how many agents, tools, and decision points your workflow actually needs.

Applied AI and data engineering projects run through four phases: Discovery, where we understand the problem and data; Architecture, where we design the model, RAG, or pipeline approach; Development, where it gets built; and Deployment, where it goes live in your environment. This is separate from the step-by-step process we use specifically for agent builds.

Yes, prompt injection and jailbreak testing on the systems we assess follows the OWASP Top 10 for LLM Applications, covering both direct injection, where the attacker types the malicious instruction, and indirect injection, where it arrives hidden inside a document, webpage, or other content the model later processes.

Yes, that's specifically what Data Leakage Prevention testing checks for. We test whether a model can be coaxed into revealing its system prompt, other tenants' data, or other information it shouldn't disclose, not just whether it hallucinates. If it can be talked into exposing that, it's flagged as a finding with evidence, not just a warning.

Data poisoning is when training or retrieval data is deliberately corrupted so a model learns or retrieves the wrong thing. It's one of the attack surfaces we look at alongside prompt injection, insecure tool-calling, and data exfiltration through model outputs, since a poisoned RAG index can be just as damaging as a compromised model.

Engagements run against an agreed plan with built-in checkpoints and escalation paths, so a critical finding does not wait for the final report. It gets raised to you as soon as it is confirmed, with enough evidence to act on immediately, and the auditable record of that decision becomes part of the final findings and remediation register.

A structured workflow agent runs a defined, ordered sequence of steps across multiple tools, useful when the process itself is fixed but touches several systems. A single-purpose agent, by contrast, does one job with a small, fixed tool set. A stateful multi-step agent goes further, holding context and making decisions across steps rather than following one fixed script.

Rates are productized rather than a custom mystery quote: an Agent Feasibility Sprint, a single-purpose agent build, a structured workflow agent, a stateful multi-step build, and ongoing care and evaluation are priced as distinct, defined engagements. You know which tier you are buying and what it covers before work starts, rather than waiting on a bespoke proposal.

Yes, the AI security service is built for both commercial engagements and government or regulated programs, and government and regulated program owners are one of the groups it is explicitly designed around. Whether the client is commercial or government, the same evidence-led delivery standard applies: scope is baselined, work runs with traceability, and capability is transferred at close-out.

Yes, that's specifically what Agentic Workflow Security testing checks for. We review the tool-calling permissions and guardrails an autonomous agent has, looking for ways it could be manipulated into taking an action outside what it was meant to do, separate from testing the model's text responses. Findings come with evidence showing exactly how the manipulation worked.

That's something Bitkosh works through with your finance stakeholders directly, not something decided unilaterally by engineering. Agentic projects are scoped with model cost ceilings from the start and finance is named as one of the roles the work is designed around, specifically so there is visibility into what the agent costs to run and where any savings actually show up in your numbers, rather than that being assumed after launch.

After an agent ships, it moves into a care and evaluation phase rather than being left to run unattended. This covers watching it in your environment, checking outputs against the evaluation test set as conditions change, and using logging and cost controls to catch an agent that gets stuck before it runs up a bill.

Yes, part of what you receive is a runbook and handover so your team can operate and extend the agent yourselves rather than staying dependent on us. It is documented alongside the tool integrations, approval rules, and evaluation test set, so operating the agent day to day does not require calling us for routine changes.

It helps a great deal if you do. Existing runbooks and documented processes give us the clearest starting point, since they describe the steps, decision points, and exceptions your team already follows, which is exactly what needs to be turned into tool calls, guardrails, and approval gates. If you don't have one written down, we can build one with you first.

It depends on what the task needs. Generative AI and RAG is the right fit when people need fast, grounded answers from your enterprise data, essentially a smarter search and drafting layer. Agentic workflows go further, taking actions through governed tools to automate a decision end to end. Many projects start with a copilot and add agentic steps later.

Because most problems do not actually need a complex, stateful system. We build a single agent with a small tool set and run it against real cases first; if that thin version handles the work, there's no reason to add complexity. The cases that genuinely need a more stateful, multi-step build reveal that quickly, rather than being assumed upfront.

Yes, that is the Generative AI and RAG offering: a secure, LLM-powered copilot with retrieval-augmented generation strictly grounded in your enterprise data layer, so answers come from your own documents and systems rather than the open internet. It is built as an isolated architecture so the underlying data is not exposed to public model training.

We specifically test for this under data leakage prevention. Testing checks whether a model can be coaxed into revealing another tenant's information, not just its own training data or system prompt, so a query from one customer cannot surface content belonging to another. This sits alongside RAG access-control review, which checks the same boundary at the retrieval layer.

Data silos and manual, repetitive workflows are usually what actually traps value inside a business, more than the choice of AI model itself. Off-the-shelf AI tools often make this worse because they can hallucinate or violate data privacy. Bitkosh's applied AI work targets the underlying problem directly, with bespoke ML models, secure RAG architectures, and data engineering pipelines built around your existing data instead of a generic tool layered on top.

We build an evaluation test set from your own historical work, then measure the agent against real cases from that set. That turns a subjective impression like "it seems better" into a number you can check after every change, so improvements or regressions in the agent's output are visible before it goes anywhere near production traffic.

Once scope is confirmed, specialists work through an agreed evidence-led plan with defined checkpoints and escalation paths, keeping an auditable record of every decision and action taken during testing. This traceability is what lets your leadership verify progress mid-engagement rather than only at the final readout, and it feeds directly into the technical findings you receive at close-out.

Yes, the same delivery standard applies to agentic AI builds as to security engagements: the work is structured for both a commercial client and a government program, with guardrails, approval gates and an audit trail agreed before any prompt is written. Whether it's a private company or a government program, technical teams can act on the design and leadership can verify progress against it throughout the build.

We set that before, not after. Before any prompt is written we agree what the agent may touch, which actions need approval, what data it may retain, and what it must never do. That decision is treated as the actual design work, not paperwork added once the build is already underway.

We configure them to your existing structure rather than a generic template. As part of project delivery you get approval and escalation rules set up against your actual roles, so a refund, an access change or another sensitive action routes to the right person for sign-off, not just a fixed queue.