Approach comparison
This page lays out the differences between unstructured, convenience-driven adoption and a measured, process-first approach — so you can form your own view.
← Back to homeWhy comparison matters
AI tools for business have become easy to acquire. The cost of starting is low; the friction of signing up for a service and pointing it at a process is often minimal. That accessibility is useful — but it also means the step of evaluating whether the tool is working, or whether it was the right tool for the situation, frequently does not happen.
The comparison on this page is not an argument against using AI. It is an argument for knowing what you are getting from it. The differences described here are about how much evidence an organisation collects before, during, and after adoption — and what that means for decisions made later.
Side by side
| Dimension | Typical adoption | Kirameki approach |
|---|---|---|
| How it starts | A team member finds a tool, signs up, begins using it. Decision is decentralised and often informal. | Engagement begins with scoping — identifying which process will be examined and what will be measured. |
| Baseline recording | Rarely done. The existing process is considered known, even when figures have not been recorded. | Completed before any change is made. Time, error rate, volume, and cost are documented. |
| Comparison method | Informal impression — team members sense whether things are faster or easier. | Both approaches run in parallel over the same period. Figures from each are compared directly. |
| Written output | Typically none. Knowledge lives with the person who set up the tool. | A written comparison report is delivered at project close. Decisions can be explained to stakeholders. |
| Option to stop | Stopping is socially difficult once a tool is in use; sunk cost is felt even if return is unclear. | Discontinuing is presented as a reasonable outcome in the decision framework delivered at the end. |
| Policy and governance | Developed after problems arise, if at all. Often reactive rather than planned. | A separate engagement establishes rules before issues occur, including a register of tools in use. |
| Data quality | Assumed adequate until automated systems fail or produce errors. Addressed under pressure. | A dedicated engagement addresses data before automation relies on it. A data dictionary is delivered. |
Distinctive elements
Every engagement defines its own boundaries before work begins. This prevents the common pattern of a pilot quietly expanding beyond what was agreed.
We do not rely on the feeling that things are going better. Figures are recorded at the start and compared with figures from the end of the pilot period.
Reports, data dictionaries, and policy documents are written and handed over. Knowledge does not sit with the consultant after the engagement ends.
Existing processes are not switched off during a pilot. Old and new run side by side, so comparison uses the same time period for both.
Kirameki does not sell or represent software products. Recommendations come from the client's situation, not from a preferred vendor relationship.
The decision framework at the end of every pilot explicitly frames stopping as a valid outcome, not a failure. This is rarely true of tools that are already embedded.
Effectiveness
The research on enterprise AI adoption consistently points to the same gap: tools are acquired at a higher rate than they are evaluated. The following reflects common findings across multiple industry reviews, rather than any single study.
Investment transparency
The cost of a structured engagement is visible upfront. The cost of unstructured adoption tends to be harder to see — until something goes wrong.
Setup cost
Kirameki engagements have a fixed price known before work starts. Costs do not accumulate silently through trial periods, renewal defaults, or expanding seat counts.
What you carry forward
Hidden costs of no structure
Client experience
Typical path
Tool is adopted, often by one person, and use spreads informally through the team.
When asked if it is working, the answer is a general yes — but no figures exist to support that.
An issue surfaces — an error, a data problem, a question from legal or compliance.
Response is reactive. Documentation is created under pressure. The tool may be restricted or removed.
Kirameki path
Conversation to identify one process and agree what will be measured before and after.
Baseline is documented. Pilot runs in parallel. Both are observed over the same period.
Written comparison delivered. Results are what they are — positive or otherwise.
Client decides whether to continue, adjust, or stop. The decision is supported by evidence they own.
Long-term view
AI integration that begins with measurement tends to age better. When results are documented, organisations can compare subsequent changes against a known baseline. When staff leave, documentation preserves institutional knowledge. When regulators or auditors ask what tools are in use and why, written records provide answers.
The alternative — adoption without documentation — tends to produce organisational dependencies on tools whose value is unclear and whose governance is underdeveloped. Addressing that later is possible, but it requires the same work that a structured approach does upfront, with the added difficulty that the baseline no longer exists.
Clarifications
A nine-week pilot is slower than signing up for a tool today. It is considerably faster than discovering six months into use that the tool was not producing the benefit assumed — and then having to make a decision without evidence either way. The pilot is not a delay; it is the evaluation that would otherwise not happen.
That may well be true. The question is whether you have figures to support that, and what you would show a regulator or a new director if asked what you are using and why. A governance engagement does not require a problem to be useful — it produces documentation and a register that make the existing usage auditable and explicable.
Six to eight weeks is the standard range. The scope is one dataset or one cluster of related records — not the organisation's entire data estate. The goal is to get a defined set of records into a state where automated systems can rely on them, and to leave validation rules that keep new records consistent going forward.
Kirameki engagements are deliverable-based. A pilot closes with a written comparison. A data engagement closes with a documented dictionary and a cleaned dataset. A governance engagement closes with a written policy. If those documents exist and are useful, that is the outcome — independently of what the organisation does next with them.
Summary
For organisations new to AI adoption
A contained pilot is a low-commitment way to find out what AI handling actually produces in your context — before committing further resources or changing staff workflows broadly.
For organisations already using AI tools
A governance engagement produces the documentation and oversight register that makes existing usage auditable — important when regulatory attention on AI in business is increasing.
For organisations planning automation
A data preparation engagement addresses the records automation will rely on — reducing the risk that errors in source data become errors in automated output.
For organisations that need to explain decisions
Written reports and documented baselines mean that when directors, auditors, or regulators ask what you are doing with AI and whether it is working, you have something to show them.
Next step
Kirameki can discuss which engagement — if any — would be relevant for your current situation. There is no obligation to commit to anything from an initial conversation.
Get in touch