AI Solutions by Business Function
Twelve business functions, each with its own budget, its own systems and its own measure of success. Written for the person who has to run the function rather than the one presenting the transformation programme.
A function owns the problem and rarely owns all of the data.
This is the structural fact that decides most function level AI projects, and it is almost never in the business case. A sales team's most valuable signal sits in finance's billing records. An HR team's outcome data lives in the business units it serves. Legal's real exposure is in contracts that procurement negotiated and operations signed. A security team can see the network and not the change history that explains it. Each function can specify a useful system and none of them can unilaterally supply the data that system needs.
The practical consequence is that the first question in a functional engagement is not which model to use. It is which data you control, which you can obtain with a conversation, and which would require a programme you have not been funded for. We answer that in the first two weeks, and on a fair number of occasions it has changed the project from the one that was requested to the one that can actually be delivered. That is a better outcome than a build which stalls in month four waiting for an extract nobody has agreed to provide.
Where AI earns its place across business functions
Ranked by evidence rather than by how often it appears in a vendor roadmap. The maturity column is our own read and the catch column is what the demonstration leaves out.
| Where | What it does | Maturity | The catch |
|---|---|---|---|
| Document and record extraction | Turns contracts, invoices, forms and reports into structured data. | Proven | The strongest application in almost every function and the one least often funded on its own. |
| Retrieval across the function's own knowledge | Finds prior work, precedent and guidance with provenance attached. | Proven | High value everywhere. Telling current material from superseded is the design problem, not the search. |
| Enquiry and request handling | Answers routine questions and routes the rest. | Proven | Reliable on routine volume. It degrades exactly when the request is unusual, which is when it matters. |
| Forecasting and planning | Predicts demand, volume, cost or headcount. | Strong | Works where history is long and stable. Business series break at policy changes, and models do not anticipate them. |
| Triage and prioritisation | Orders a queue by urgency, value or risk. | Strong | Ordering work is defensible. Removing an item from the queue entirely is a decision that needs a person. |
| Drafting from your own material | Produces first drafts constrained to your templates and language. | Strong | Real time saving. Constrained to your own corpus it behaves; open ended generation is where it invents. |
| Anomaly and exception detection | Flags transactions, records or behaviour that departs from normal. | Strong | Effective, and the alert has to carry a reason a person can act on or the queue gets ignored. |
| Scoring people for a decision | Ranks candidates, employees, customers or claimants. | Regulated | High risk under the EU AI Act in employment and credit. Outcome testing is the requirement, not clean inputs. |
| Autonomous execution without review | Acts on a decision with no person in the loop. | Rarely defensible | Almost always proposed before the audit trail, the appeal route and the rollback path exist. |
The measure you are judged on is rarely the measure the model optimises
A sales director is judged on quota attainment and a lead scoring model is judged on ranking accuracy. A support director is judged on cost per contact and customer effort while a deflection system reports containment. A finance team is judged on a clean close and a reconciliation model reports match rate. These pairs are related and they are not the same, and the gap is where good technical projects quietly stop mattering to the person who paid for them. We ask what number your performance review actually contains before scoping anything, because that question changes what gets built more reliably than any workshop about objectives.
The obligations that follow the function, not the industry
Some AI regulation applies by sector. A good deal of it applies by what the system does, which means it follows the function across every industry. This is our reading as at September 2026 and we work alongside your legal and compliance teams rather than in place of them.
The most regulated function in any company
AI used for recruitment, selection, promotion, termination, task allocation and worker monitoring is high risk under Annex III of the EU AI Act, with obligations from 2 December 2027. Several US regimes already apply: New York City requires an annual independent bias audit with published results and candidate notice, Illinois has required notice since 1 January 2026 and prohibits using zip codes as proxies, and California regulations effective 1 October 2025 extend retention of automated decision system data to four years including training data.
In force since 2 August 2026
Article 50 of the EU AI Act requires that people are told when they are interacting with an AI system, that synthetic audio, image, video and text carry machine readable marking, and that deepfakes are disclosed. Penalties reach 15 million euro or 3 percent of worldwide annual turnover. For marketing, customer service and product teams this is a production and workflow obligation rather than a policy one.
Annex III reaches finance directly
Evaluating the creditworthiness of natural persons is high risk, as is determining eligibility for essential public benefits and services. Finance teams building customer risk scoring should establish the classification early, because the documentation and testing requirements shape the build rather than describing it afterwards.
Older than any AI statute and frequently binding first
Legal privilege, client confidentiality, auditor independence and professional competence duties apply to work produced with AI exactly as they apply to work produced by a person. Courts have been consistent that the obligation to verify what you file does not change because a machine drafted it, and the public record of failures is now substantial.
Purpose, minimisation and the basis you actually have
Most functional systems process personal data about customers, employees or both. The recurring failure is purpose creep: data collected for one function gets reused by another under a lawful basis that did not contemplate it. Mapping what you hold and what you may use it for is unglamorous and it is the work that prevents a system being switched off after launch.
Frequently tighter than the regulation
Client agreements, supplier contracts and data processing terms increasingly restrict AI use, require disclosure, or prohibit data leaving named environments. In our experience these bind organisations sooner and harder than any statute, and they are usually reviewed after a tool has been selected rather than before.
What this means for a build
Three consequences. Establish which data the function actually controls before scoping, because that determines what is buildable rather than what is desirable. Identify anything that scores a person early, since employment and credit decisions carry obligations that change the design rather than the paperwork. And check what your own contracts permit before selecting a tool, because that review takes a week and prevents an expensive reversal. See AI consulting and AI risk assessment.
Who we write for
Each page starts from that organisation's own problems, names the regulatory exposure it carries, and routes into the engineering. Depth varies and is stated on each page.
Sales
Forecast accuracy, pipeline hygiene and account prioritisation, built on what your CRM actually contains.
Read more →Marketing
Content production, channel analytics and reporting, with the labelling obligations handled in the workflow.
Read more →Customer Service
Agent assistance, quality analysis and triage, measured on repeat contact rather than containment.
Read more →Finance & Accounting
Extraction, explainable exceptions and reconciliation, documented to a standard a reviewer will accept.
Read more →Human Resources
Attrition modelling, operations and sourcing, built around rules that are already in force.
Read more →Legal & Compliance
Contract extraction, precedent retrieval and policy checking, built around a verification step that actually happens.
Read more →Operations
Backlog analytics, scheduling with real constraints and exception handling, built to be used rather than admired.
Read more →Supply Chain & Procurement
Spend analytics, demand forecasting and supplier risk, with the data you do not own handled honestly.
Read more →IT & Engineering
Service desk automation, incident analytics and documentation retrieval, with review capacity treated as the real limit.
Read more →Security & Risk
Alert quality, explainable detection and risk analytics, built for an adversary that adapts.
Read more →Product & R&D
Feedback synthesis, experiment analysis and literature retrieval, with the decision left where it belongs.
Read more →Executive & Strategy
Portfolio assessment, board reporting and governance, including which projects should stop.
Read more →FAQ
Marked up with FAQPage schema so these answers can surface in search results and inside AI assistant responses.
How is a solution page different from an industry page?
An industry page answers what AI does in your sector. A solution page answers what AI does for your function, which is a different question with a different buyer. A head of customer service in a bank and one in a utility share more problems with each other than either shares with their own colleagues in risk. If you know which function owns the budget, start here. If the sector specific regulation is the binding constraint, start with the industry pages and come back.
What is the most common reason functional AI projects stall?
Data the function does not control. A sales team's best signal is in finance's systems, HR's outcome data lives in the business units, legal's exposure sits in contracts procurement negotiated. Each function can specify a useful system and none can unilaterally supply what it needs. We establish in the first fortnight which data you control, which you can obtain with a conversation, and which would need a programme nobody has funded. That answer frequently changes the project, which is a better outcome than discovering it in month four.
Which function usually gets the fastest return?
Whichever one is drowning in documents, and in most organisations that is finance, legal or customer service. Extraction from invoices, contracts, forms and correspondence is the most reliable application anywhere in this list, the errors are checkable against the source, and it touches no decision about any person. It is also almost never the project a function arrives asking for, which tends to be a prediction model with a longer path to value.
Do we need a separate AI strategy for each function?
You need a shared governance position and separate delivery plans. The obligations that matter are largely the same across functions, so one policy, one risk assessment approach and one set of standards for documentation and testing is more efficient and more defensible than twelve. What differs is the data, the systems, the measure of success and the appetite, and those belong in each function's own plan. Trying to run one programme across all twelve usually produces a roadmap that satisfies nobody.
What should we do before commissioning anything?
Write down the number your function is judged on, and check whether the proposed system moves it. A great deal of functional AI work optimises a technical measure that is related to the business outcome without driving it, and that gap is why projects deliver on time and stop mattering. If the system improves ranking accuracy while the function is measured on cycle time, somebody should notice that before the build rather than at the review.
Start with the problem, not the technology.
Thirty minutes, no charge, no deck. Tell us what is going wrong in your organisation and we will tell you whether AI is the right instrument, including when it plainly is not.