Implementing artificial intelligence to grow a communications agency

AI becomes useful in a communications agency when the team starts with a specific process, observes how it actually works and defines the decision the pilot must support, instead of beginning with tool comparisons or collecting demonstrations.

• Target process: choose a frequent, bounded flow, such as turning an approved brief into copy variants for review, classifying client feedback or preparing a campaign report.
• Observable friction: name the current problem — waiting, rekeying, errors, variable quality or weak traceability — without assuming that AI is automatically the best answer.
• Required decision: state from the outset what evidence will support stopping, correcting or expanding the trial.

1. Choose a process that can genuinely improve

A sound first use case combines sufficient volume, identifiable inputs, a reviewable output and manageable risk, because a rare, unstable or unevaluable process mainly produces an attractive demonstration with little operational value.

• Input: the brief, sources, brand rules and access rights are available in a usable format.
• Transformation: the steps are regular enough to describe, even when some decisions remain human.
• Output: an accountable person can recognise an acceptable result and explain a rejection.
• Risk: an error can be detected before publication, billing, a client commitment or a decision about a person.

Preparation tasks are often a safer starting point than autonomous execution: AI can suggest a first version, classify material or flag inconsistencies while the team retains editorial, commercial and legal approval.

• Creation: headline variants from an approved brief, a sourced document summary or adaptation of an already approved format.
• Operations: preliminary classification of inbound requests, extraction of fields from meeting notes or preparation of an editorial calendar.
• Analysis: grouping feedback, identifying themes and preparing hypotheses that an analyst checks against the underlying data.

2. Measure the baseline before the pilot

The value of a pilot should be judged by the difference from a baseline describing the current process’s cost, elapsed time, quality and rework, rather than by an impression of speed during a demonstration.

• Effort: human time spent on each stage, including coordination, research and corrections.
• Elapsed time: the period from receiving a complete input to delivering an approved output.
• Quality: factual errors, brand deviations, missed instructions and reasons for rejection observed across a representative sample.
• Rework: the number and nature of iterations needed before acceptance.

The baseline must be light enough for the team to maintain and stable enough to compare like with like; otherwise, a quiet week, a better brief or a more experienced colleague can be mistaken for an effect of the tool.

• Use the same start and end points for the baseline and pilot processes.
• Compare work of similar complexity and record exceptions.
• Include review, correction, configuration and support time in the cost of the AI scenario.

3. Prepare the data and working rules

Before connecting a model to the CRM, archives or advertising accounts, the agency must distinguish the data that is necessary, permitted and dependable from material that is obsolete, duplicated, confidential or lacks a clear owner.

• Necessity: provide access only to the fields and documents required for the use case.
• Quality: identify authoritative versions, missing data and content of uncertain provenance.
• Rights: check client contracts, intellectual property, the basis for processing personal data and the supplier’s terms.
• Lifecycle: set rules for retention, logging, correction and deletion.

A model does not spontaneously turn a disorganised document store into dependable knowledge: sources need structure, their origin must remain visible, and the expected response to missing or contradictory information must be defined.

• The system cites or links the sources it used when factual review requires them.
• Approved content is separated from drafts, examples and outdated documents.
• A lack of evidence prompts a request for information or an abstention, rather than a plausible invention.

4. Assign ownership of the result, risk and tool

The pilot needs a business owner who can judge quality and a technical owner or supplier who can correct the system, with explicit responsibilities for security, data and final acceptance.

• Business owner: defines acceptable cases, reviews errors and decides whether the process genuinely serves the client.
• Operational lead: maintains instructions, gathers incidents and supports users in their daily work.
• Technical owner: manages integrations, access, versions and reversibility.
• Control functions: contribute according to risk on data protection, security, legal, procurement or employment matters.

Human oversight must correspond to a real decision: asking someone to click ‘approve’ protects neither the client nor the agency if that person lacks the time, information or authority to challenge the result.

• Present the sources, uncertainties and transformations needed for review.
• Allow review time proportionate to the consequences of the output.
• Give the reviewer authority to correct, reject and suspend the flow.

5. Build a bounded, reversible pilot

A useful pilot tests one hypothesis within a chosen scope — one team, one type of deliverable and one dataset — while preventing an unchecked result from reaching a client or audience directly.

• Hypothesis: for example, reduce structural revisions to a campaign report without increasing factual errors.
• Scope: specify users, assignments, languages, channels and permitted actions.
• Safeguards: require review before release, restrict permissions and retain the material needed to investigate an incident.
• Reversibility: prepare a return to the previous process and an export of data or instructions if the tool is abandoned.

The trial must capture failures as well as successes, because an acceptable average can conceal a type of brief, language or client category for which the solution becomes costly or unsafe.

• Classify errors by consequence rather than frequency alone.
• Record rejected cases, workarounds and tasks shifted to other members of the team.
• Ask users about the review burden, their understanding of the system and the confidence they can reasonably place in it.

6. Treat uses involving people separately

Recruitment, filtering applications, task allocation based on individual characteristics and some forms of worker evaluation can fall within the high-risk systems listed in Annex III of the AI Act, so they should not be added to an ordinary productivity pilot without a dedicated assessment.

• Identify the system, its intended purpose and the agency’s exact role — provider, deployer or another actor — before determining the applicable duties.
• Examine data quality and representativeness, discrimination risks, information provided to people and routes for redress.
• Arrange competent, effective human oversight and document decisions and incidents as required by the applicable framework.
• Consult the official text of the EU AI Act and relevant legal advice for the specific case.

7. Decide whether to stop, correct or expand

At the end of the pilot, management should compare the results with the baseline and consider quality, full economics, adoption and risk together, because a production gain can be cancelled by review work, incidents or supplier dependence.

• Stop if the original problem remains marginal, serious errors are not controlled or the total cost outweighs the observable benefit.
• Correct if the hypothesis remains credible but the data, instructions, review interface or scope explain the shortcomings.
• Expand only if the agreed criteria are met on representative cases and the team can absorb the additional training, support and governance.

A successful expansion changes the standard process, not merely the licence count: it formalises who uses the tool, on which data, with which controls, and how performance will be reassessed when the model, supplier or business changes.

• Update the procedure, responsibilities and training before opening the new use.
• Track a small set of indicators tied to the original problem rather than an exhaustive dashboard.
• Review access, costs, errors and contract terms after every material change.

A workable implementation sequence

The agency can proceed through successive decisions, each producing something that can be checked before it commits more data, users or budget.

• Frame: select the process, owner, principal risk and required decision.
• Observe: establish the baseline and assemble a representative set of cases.
• Prepare: clean the sources, restrict access and define acceptance criteria.
• Test: run the bounded pilot, record the results and maintain a fallback.
• Decide: stop, correct or expand using the agreed criteria, then document the new way of working.

This discipline turns AI into a concrete management choice: the agency knows which problem it is addressing, who is accountable for the result and what evidence would justify the next investment.

• Clients receive a more consistent service only when final quality remains controlled.
• Teams save time only when measurement includes preparation, review and rework.
• Management can invest progressively because each stage retains an explicit exit route.

Paul-Antoine TUAL · AI Transformation Leader · Croissance & Transitions