Artificial intelligence (AI) is rapidly transforming industries, creating real opportunities for efficiency and growth. However, navigating the complex world of AI and implementing AI solutions can be a daunting task. Oblytech’s AI Consulting and Implementation services can help your organization work out where AI fits, from defining an AI strategy to building and deploying AI solutions.
The first decision in most AI initiatives is not which model to use. It is who carries the work from an idea to a supported production service. The AI and machine-learning services range covers several of the stages involved, and the right starting point depends on which of them is already settled.
Three routes are common. An internal team can build the capability, which gives the most control and takes the longest to reach a result. A packaged product can be configured, which is quicker when the use case matches the product closely and becomes expensive when it does not.
A consulting-led engagement or partner delivery team can design the approach, build the first release and hand over operating responsibility, which suits organizations that need a specific outcome before they have the staff to deliver it. Many organizations end up using a mixture, and the honest question is which parts of the work they cannot afford to get wrong while they learn.
| Route | Usually suits | Main risk | What must be true first |
|---|---|---|---|
| Internal build | Long-term differentiating capability with a stable team | Slow start and uneven skills across the first releases | A named owner, funded time and a technical lead who has shipped production software |
| Configured product | A common use case that the product was designed for | Forcing the business process to fit the product’s assumptions | A written list of the process steps the product must not change |
| Consulting-led pilot | A use case that is clear in principle but unproven in the organization | A pilot that never reaches an operating owner | A decision on who runs the service after the pilot ends |
| Partner delivery team | Capacity gaps during design, build or first operation | Knowledge concentrated outside the organization | Documentation, access and knowledge transfer written into the terms |
None of these routes removes the need for a decision owner inside the business. A partner can design and build a workflow, but only the business can say which outcome matters and what a wrong answer costs. Engagements that stall often do so because that person was never named, not because the technology failed.
A first engagement should end with something the organization can decide on, even if the decision is to stop. That usually means a use case with a stated owner, a description of the data and systems it depends on, an evaluation approach that someone can run, and a view of who will operate the result.
Work that ends with a strategy document and no route into a pilot is common and of limited use, because the strategy is then tested for the first time by people who were not in the room when it was written.
It is worth asking for the outputs in writing before the work starts. A reasonable set includes a ranked list of candidate use cases with the reasoning behind the ranking, a design for the first release with its inputs and outputs named, a list of the risks the design accepts and those it refuses, and a plan for measuring whether the release did what it was meant to do.
Each of those items can be checked by the buyer. Vague promises of transformation cannot.
A well-run AI engagement tends to move through four framing stages. The first defines the problem and the decision the AI will support. The second checks whether the data and access needed for that decision exist and are usable.
The third designs a release that is small enough to test and bounded enough to stop. The fourth decides how the release will be operated after the project team leaves. Teams often rush the first stage because it feels like admin, then discover at the third that the decision was never agreed.
The most common slowdown comes from data access that was assumed rather than confirmed. A business sponsor believes the required information is in one system, while the people who run that system know it is split across two, with a delay in the second and a license restriction on the export.
A short conversation with the system owner in the first stage is cheaper than discovering this in the middle of a build. The use case discovery page lists data sources, quality limits and access boundaries among the things to describe before a use case is pursued.
Cost and length follow the amount of unknown in the problem more than the amount of code. The factors that most often change an estimate are the number of systems the AI must read from or write to, the state of the source data, the number of people who must approve a decision, how much of the business process is written down, and whether the output must be explained to a regulator or an auditor.
A buyer who arrives with a list of systems, a named sponsor and a description of the decision will get a more useful proposal than one who arrives with a budget and a hope.
This question is the one most often left until the end, and it should come first. An AI capability that was designed by one group and operated by nobody will decay as models, prompts, source data and user expectations change.
The operating owner needs to understand the design decisions, the evaluation results, the known limitations and the conditions that should trigger a review. Knowledge transfer that consists of a recorded walkthrough is not enough. The handover should include the test cases, the escalation path and the process for changing the design.
Organizations that already run a governed enterprise AI strategy often have an easier time with this, because the governance decisions were made in advance and the operating owner knows where to find them. Those without one can still make the handover work by writing down the decision rights before the build begins.
A pilot makes sense when the organization can name the users, the case volume, the output that will be reviewed and the condition for stopping. It does not make sense when the pilot exists mainly to show that AI has been tried.
A pilot should answer one question, such as whether a particular class of request can be handled with acceptable review effort, and it should be designed so that a negative answer is a useful result. The AI workflow pilot page on the ServiceNow side also frames a pilot around one workflow decision within a defined boundary, which is relevant when the target platform is already in place.
The provider should be able to show draft evaluation criteria in the first stage, before the build starts. If criteria only appear at the end, they are often written to fit what was built.
A sound engagement says in advance how it will report a negative finding and what the buyer keeps. Ask to see that answer in writing. An engagement with no route to a stop decision tends to continue for longer than it should.
Every engagement has boundaries. Ask about model hosting, ongoing monitoring, data cleansing in source systems, and changes to policy. Boundaries that are clear on day one prevent disputes later about what was included.
The answer should name roles, not just training sessions. Look for named operating roles, a shadowing period on real cases and a documented process for changes after handover.
If you are weighing a build, a pilot or a partner-led engagement for an AI use case, start with the decision the AI would support, the systems it would need and the person who will own the result. Start a conversation about which route fits and what the first stage should cover.
AI implementation support is the work that keeps a released AI workflow accurate, owned and safe to use after the project team has left. Most implementations need it for longer than the build itself, because the business process, the source data and the people using the output all keep changing.
The support work usually falls into four areas. Output quality needs regular sampling against the criteria agreed at the start. Incidents need a route, so that a wrong answer reaches a named person rather than a general inbox. Changes to the process or the systems behind the release need a small change process.
The scope needs a review date, so the team can decide whether the AI should keep its current role.
| Area | During the build | After go-live |
|---|---|---|
| Output quality | Evaluation set agreed and first results checked | Regular sampling of live outputs against the same criteria |
| Incidents | Failure modes listed in the design | A named owner, a response route and a log of every wrong answer |
| Changes | Requirements frozen for the first release | A change request for each update to the process, data or systems |
| Scope review | Success measures written down | A dated review of whether results still justify the scope |
The common failure here is a support gap that nobody notices until a user stops trusting the output. Staff start checking everything by hand, usage falls, and by then the people who knew why each design choice was made have moved on.
A short support agreement, signed before go-live, goes a long way toward preventing this. It should name who checks the outputs, how often, what counts as a failure and who can switch the release off. Teams with a clear model for running AI usually find this step short.
Support is also where the first version of the model meets change. A new document type, a changed approval threshold or a renamed field in a connected system can lower accuracy without raising any error. Sampling outputs each cycle is the most reliable early warning, which is why the checks that show whether outputs are still right belong in the support plan rather than only in the build report.
Where a delivery partner is involved, a planned knowledge transfer decides whether the support plan can run without them. Write the handover list early, while the people who built the release are still on the project.
No. A partner cannot take over the call on which result matters or what an error would cost. Teams that stall tend to be the ones that never named that person, rather than the ones whose technology let them down.
Usually not. A strategy document unattached to any pilot is of little use, since the first people to test it are often those who had no part in writing it. The initial phase should close with a call the organization can act on, even when that call is to stop.
Most slowdowns trace back to data access that was taken for granted. The sponsor may picture one system holding everything, whereas the team running it knows the data sits in two places, one of them delayed and the other with export limits.
Unknowns in the problem drive the price and timeline more than code volume does. The biggest levers are how many systems are involved, how messy the source data is, how many approvers sign off each decision, and how fully the process is documented.
Support usually runs longer than the build, because processes, data and users all shift over time. Before go-live, a brief agreement should cover who reviews outputs, how frequently, what qualifies as a failure, and who holds the authority to pause the release.
AI implementation services take a use case the business has already chosen and turn it into a tested release people use in daily work. They do not decide which problem is worth solving. If that decision is still open, discovery work should come first.
You are ready to buy implementation when the decision and its owner are named, the source data has been checked by someone who knows the systems, the result can be checked by a reviewer, and an operating owner is identified. The table below shows what each signal looks like.
| Signal | Ready to buy implementation | Not yet: start with discovery |
|---|---|---|
| Use case | One decision is named, with the person who owns it | Several candidate problems and no agreed ranking |
| Source data | Access checked with the people who run each system | Believed to be in one place, with no one having looked |
| Evaluation | Test cases exist before any build starts | Plan is to judge the output once it looks right |
| Operation | An operating owner is named for after go-live | The expectation is that the provider will run it |
If most rows fall in the right-hand column, a short discovery stage is usually cheaper, because a build started on an unclear decision tends to be rebuilt. A use case discovery review ranks candidates before any build, and a data readiness check confirms access early.
The common mistake is to read a working demo as proof. A demo shows the cases someone picked, usually the clean ones. A useful test set includes ordinary volume and the awkward cases, and it should exist before the build. How to check AI outputs before anyone relies on them is a useful next read.
A sound first milestone is typically a written go or no-go note, not a working model. It states the decision, the measured result against the agreed test set, and the proposed operating owner. A no-go note still has value, because it stops the same idea returning without new evidence.
An AI implementation is ready for go-live when it has passed a test the business agreed before the build started, run on cases the design did not use. The test should draw on real past cases with known correct outcomes, scored by a reviewer who did not build the release. Set the pass mark, the sample size and the rule for a failed result before the first run, because a threshold chosen after the results are in tends to fit whatever came out.
Most go-live reviews go wrong in one of two ways. The first is accepting a demo, where the sponsor picks the examples that look best and the release is signed off on a handful of outputs. The second is judging the output by eye. Neither shows how the release behaves on incomplete records, conflicting instructions, or requests outside the scope the design allows.
A useful acceptance pack usually holds four things: a sample of recent live cases with the expected output recorded for each, the failure modes named in the design with a test that tries to trigger each one, a rule for what the release does when it cannot answer, and a short record of the reviewer’s decisions so a later change can be checked against the same cases.
A decision rule helps at the end. If the release passes the common cases and fails a known edge case, ask whether that case can be routed to a person without losing the release’s value. If it can, go live with that route in place. If the failures hit the cases the business cares most about, return to design rather than widening the scope.
Correct output is not the same as useful output. Agree which measure will show the release is worth keeping, such as time to finish a task or the share of cases closed without rework, and record the baseline. The way to measure whether an AI release is paying off belongs in the same meeting as the pass mark.
After go-live, the same cases become the basis for sampling. A named person should run them on a fixed schedule, and the release should have a stop condition tied to the pass mark. Plan the review of live outputs and who keeps it running before launch, and put approval controls for AI outputs in place wherever an output reaches a customer or an auditor.
A fixed-scope release suits an AI implementation when the use case, the data it reads and the test for success are known before work starts. An open-ended build suits the case where one of those is still unknown and the work has to answer it. Most buyers need a mix, and the contract should show which part is which.
Fixed scope works when the output can be checked against a written acceptance test. A classifier that routes incoming requests, for instance, can be scored on a held-back sample of past requests against a threshold agreed in advance. The provider carries delivery risk for that release, and you carry the risk of the scope being wrong, so the scope has to be right before signature.
Open-ended work fits when the data sits across several systems, the process is not written down, or the team has not agreed which decision the AI should support. Time-based billing is easier to defend there when the engagement has checkpoints where you can stop or change direction.
| Question | Fixed-scope release | Open-ended build |
|---|---|---|
| What is known before start | Use case, data sources, acceptance test | Direction only |
| Main financial risk | Scope was wrong at signature | Spend before the answer arrives |
| What the buyer controls | Acceptance test and change requests | Checkpoints and who decides |
In most implementations the cleanest answer is to split the engagement in two: a fixed-price discovery that ends with the data check and acceptance test written down, then a release priced once discovery has shown what it needs. A proposal with no acceptance test, no priced change process or no named operator after go-live is asking you to carry risk it has not described.
Settle boundaries before the build, not after the first integration test fails. Agree which systems the release may write to, using the rules in safe boundaries for AI tool integrations. Staff who use the output also need time to change how they work, covered in driving AI adoption in daily work. If part of the delivery team works from another location, write the reporting lines for change requests as carefully as the technical scope, as set out in how accountability holds across a delivery team.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.