AI integration consulting for products beyond the demo.

Fit the AI to the operating conditions.

AI integration consulting connects a model or AI capability to the workflows, data, hardware and decisions of an actual product. The question is what the system should do when its inputs are incomplete, its confidence is low, its network is unreliable or its output would trigger a costly action.

Those conditions belong in the architecture. A detector can perform well on a test set and still fail under night lighting. An LLM feature can look useful in a controlled demonstration while leaving unanswered questions about access, incorrect outputs and recovery. Integrating AI means designing the behavior around those limits, then choosing how to test it.

My published work is strongest in computer vision, anomaly detection and edge systems. LLM integration is also part of the current consulting offer. The case studies linked here are evidence for the work they describe; they are not presented as undocumented LLM deployments or as a guarantee for a different project.

A feature to ship, a model to deploy or a system to fix.

Computer vision and anomaly detection.

You need the product to respond to what a camera or sensor observes. The design has to account for missed detections, false alarms, scene changes and the action taken after a score crosses a threshold. I examine that decision path alongside the model, so a model issue is not confused with a problem in the surrounding logic.

Edge AI under hardware and cost constraints.

You want inference close to the camera or device because latency, bandwidth, privacy or central compute costs matter. The available hardware, runtime, frame rate and retention requirements shape what is feasible. A practical architecture compares the deployment options using your workload instead of assuming more central compute is always the answer.

LLM features inside an existing product.

You have a workflow where language-based assistance may help. Scoping begins with what the user needs, what data can be accessed and what should happen when an output is wrong. The proposed integration needs an evaluation approach, explicit boundaries and a fallback before it becomes a larger build commitment. The first week establishes the direction and the questions requiring further evidence.

A paid scoping week with a written direction.

For a new AI product or feature, the first step is a fixed-fee scoping week. We establish the intended workflow and operating constraints, then turn the problem into an architecture, a written specification and a fixed quote for the proposed build. The fee and boundary are agreed before the work begins.

• The decision the AI supports: who uses the result, what action follows and which mistakes are expensive.
• The inputs and environment: available data, hardware, connectivity, operating conditions and access requirements.
• The integration direction: where the capability sits in the product and how the surrounding system handles uncertainty.
• The evaluation questions: what evidence is needed to judge the proposed behavior before deployment.
• The next step: the written build scope, or a clear account of what remains unknown and how to investigate it.

If the system is already shipped and failing, start with the software project rescue diagnostic week. That engagement reviews code, hardware and field evidence to identify the cause. If the AI question sits inside a larger product design decision, software architecture consulting may be the better entry point.

What the published cases actually show.

The EV wireless-charging detector case describes a system that missed a human hand while producing false alarms from reflections. The fix addressed the decision architecture with a two-tier detector: a model-free comparison for large objects and a constrained anomaly-model path for small foreign objects.

The published result reports 98% false-alarm detection efficiency and a fix deployable without retraining. That metric belongs to this project and its conditions. The important transferable lesson is to inspect the full decision chain before paying for another training cycle. The complete false-alarm teardown explains the observations and reasoning.

The 1,400-camera ANPR architecture case describes edge inference, event-triggered retention, a three-year cost model and a six-camera reference proof of concept. It is an architecture and proof-of-concept record, not a claim that I operated a full production network of 1,400 cameras.

If you are comparing edge and central processing, the existing video analytics TCO calculator is a useful starting point. Its assumptions need to be replaced with your camera count, workload and operating costs before making a purchase or deployment decision.

Bring the uncertainty with the idea.

Do we need a trained model already?

No. A new feature can be scoped from the business problem, intended behavior and available inputs. An existing model gives us something concrete to evaluate, but it does not replace the product questions. A failing deployed system benefits from raw examples of both correct and incorrect behavior.

Is retraining always part of the work?

No. The cause may sit in the data, model, runtime or decision logic. Retraining should follow evidence that it addresses the cause. The EV case is one example where changing the surrounding architecture was the useful first move.

Can you work with US or UK teams remotely?

Yes. Engagements are available worldwide. Send the intended workflow, what exists today, the deployment environment and the decision you need to make. I will reply with whether a paid scoping week is the right starting point. Implementation and ongoing advisory are described on the consulting engagement page.