AI should earn its place in your business

Before anything is built we establish whether AI is the right response at all. The output is a decision document with numbers in it, not a slide pack.

• Process walkthroughs, not workshops. Handling time, volume and rework rate captured with the people who do the work, as the baseline every later claim is measured against.
• A register that says fund or decline. Each use case scored on business value, data readiness, risk exposure and implementation effort, with a recommendation to fund, defer or decline it.
• Readiness review before any build. Identity, permissions, document hygiene, data quality and integration surfaces assessed, producing the list of what must be fixed first.
• Business case with token estimates. Build, run and licence cost including inference volume at expected and peak load, with every assumption written down so a wrong one can be found later.
• Responsible-AI review up front. The decision each system influences, the people affected and the human approval points that must exist, named before design rather than after.
• Where we advise against AI. A written recommendation where automation, reporting or a process change would deliver more, including the cases where we say build nothing at all.

We build in increments, and each increment is something a real user can try. Reference patterns are reused across engagements so you are not funding invention where a known pattern will do.

• Retrieval designed against your documents. Chunking strategy, metadata, permission filtering at query time and index refresh cadence, tested on your real corpus rather than on samples.
• Model selection benchmarked, not assumed. Accuracy, cost and latency recorded per candidate on your own tasks, with the architecture kept deliberately model-swappable.
• Prompts held in source control. Prompts, tool definitions and orchestration logic versioned and deployed through the same pipeline as the rest of the application.
• Agents bounded by a tool schema. An explicit tool list with validated arguments, and every write into a business system gated behind confirmation or approval.
• Predictive models with a retraining trigger. A documented feature set, a holdout evaluation and the retraining condition defined before release rather than after drift appears.
• Integration through APIs, not databases. Governed APIs and event-driven workflows instead of direct database access, so the AI layer can be replaced without touching the source system.

AI inherits every access problem your environment already has and adds a few of its own. Identity, data classification and prompt-level attack surface are treated as build work, not as a review at the end.

• Answers limited to the signed-in user. Identity-based access so an assistant returns only what that person can already open, verified by testing retrieval with accounts at three permission levels.
• Excluded repositories published. Sensitivity classification and data-loss controls on the content in scope, with a written list of what is deliberately out of scope and why.
• Prompt injection kept in the test suite. Untrusted content inside retrieved documents, tool allowlists and output filtering, with adversarial cases kept permanently in evaluation.
• Any answer can be reconstructed. Prompts, retrieved sources, tool invocations and approvals logged and correlated, so a specific response can be traced during a review.
• Approval enforced in the workflow. A human sign-off for every action with financial, contractual, safety or client-facing consequence, built into the flow rather than written into a policy.
• Evidence for the framework you align to. Support assembling control mappings and evidence where your organisation is aligning to the Essential Eight or the Australian Privacy Principles.

An AI system people do not trust is shelfware with a licence attached. Adoption is planned from the first workshop and measured after go-live against the baseline we captured before it.

• Enablement built on real tasks. Role-based sessions around the work each team actually performs, rather than a generic demonstration of the tool.
• Published limits, not just capabilities. What the system is for, what it must not be used for, and what a person does when an answer looks wrong.
• A pilot group with names against it. Named participants, a feedback channel someone reads, and a fortnightly review of failed or unhelpful responses.
• Champions briefed on the weaknesses. People in each business area who understand the limitations as carefully as they understand the capabilities.
• Prompt libraries in your terminology. The handful of tasks each role performs most often, written with the phrasing that actually works on your content.
• Measured against the original baseline. A post-go-live comparison reported to the sponsor with the assessment assumptions restated, so the comparison stays honest.

Model behaviour, source content and user expectations all move after launch. We stay accountable for the system rather than handing over a repository and a diagram.

• Evaluation re-run on a schedule. Results trended against the previous baseline so a regression is raised before users find it and lose confidence.
• Thresholds agreed at design time. Latency, error rate, consumption and retrieval quality monitored, alerting on limits set before go-live rather than after an incident.
• Deprecations handled before the date. Model and platform changes tracked across Microsoft and AWS, with a tested migration plan ready ahead of any retirement date.
• Index and content health checked. Stale documents, failed ingestion and permission drift after staff or project changes, verified rather than assumed.
• Cost reviewed against the business case. Per-feature attribution with a recommendation where spend is not earning its place, including switching a feature off.
• One recommendation each month. A sponsor report covering usage, answer quality, incidents and cost, ending in the single next improvement we advise.