This started as a conversation with our eCronicle editor Rebecca Thomas about where small environmental consultancies should begin with AI. The short answer turned out to be: not where most of the advice tells you to start.
Whether AI is useful on an environmental project comes down to one thing, and it isn’t the AI. It’s whether anyone can find clean, structured, queryable records of the work. That’s why the forecast quoted in every AI panel deck doesn’t mean for us what people assume it means. When Goldman Sachs estimated in 2023 that roughly two-thirds of occupations were exposed to some degree of automation, and that the exposed ones could see a quarter to half of their tasks done by machine, it was describing professions that already sit on exactly that kind of record: accountants, lawyers, management consultants, tax advisors. Environmental consultancies, mid-sized Australian ones especially, don’t. The estimate was probably about right for the firms it described. It just wasn’t describing us.
That’s the whole article, in a way. Most of the AI advice we’re getting was written by people who looked at a consulting firm and saw databases, well-maintained spreadsheets, pitch decks, and standardised reports. They didn’t see rain-soaked field sheets photographed on a clipboard in questionable light, saved to a folder structure that depends on which PM was running which job in 2018. They didn’t see the institutional memory of why a particular well was abandoned, which lives in a single email thread that nobody can find if they tried. They didn’t see the client’s verbal feedback after GME round 3, which Mike-who-retired-last-year just kind of knew.
So when the advice arrives, it lands as homework with no operational teeth: get your data house in order, document your processes, build an AI policy. None of it wrong, exactly. It just doesn’t match how environmental consultancies actually hold their working knowledge.
Three Piles
A typical mid-sized environmental consultancy holds its working knowledge in three distinct piles, and AI behaves very differently against each.
Structured project data is the friendly pile. Lab results from chain-of-custody outputs, field parameters from calibrated probes and loggers, well construction details in a project database, water levels exported from telemetry, weather data scraped from the nearest BOM station. This pile is broadly AI-usable today, on the condition that someone has done the upstream work to harmonise IDs, naming, units, and analyte synonyms. Most firms haven’t. The standard pre-cleaning step usually takes a week per project, which is why the AI tools mostly get used on demonstration projects and rarely on the next live job.
Documents is the difficult pile. Decades of historical PDFs, scanned field sheets, regulatory letters, site investigations from previous owners, hand-marked plans, photographs with no metadata. AI can extract from these, but only if someone has built the extraction pipeline. Off-the-shelf chatbots don’t ingest a folder of 4,000 scans and just figure it out. The pipelines aren’t impossible, but they require investment that mid-sized firms can rarely defend on a single-project basis.
Tacit knowledge is the dangerous pile. The reasoning behind every judgement call that didn’t get written down. Why we shifted the screen interval at MW07. Why we excluded one bore from the trend analysis. Why we changed sampling strategy between rounds after the second site walk. Why we don’t use lab X for this analyte. This pile lives in heads, in conversations, in email chains nobody indexed. AI can’t recover it. This is the institutional knowledge that walks out the door when senior staff retire or change firms; the kind of context AI most needs and most consultancies don’t capture.
Generic AI advice treats these as one pile and recommends one fix. They are three different problems, and most of the answers aren’t AI projects at all.
Why the Firm-wide Stories Stall
Almost every firm-wide AI adoption story I’ve watched up close has the same shape. The leadership team buys a tool. A small group of enthusiasts uses it for a few months. The wider firm doesn’t adopt, because there’s no way to point the tool at the actual work. The documents pile is unreadable, the tacit knowledge isn’t documented, and the structured data needs the same week of cleaning every time.
The bottleneck isn’t the tool. It’s that the firm needs someone whose job is to take the unstructured piles and make them AI-readable. That’s an unglamorous, multi-year role nobody wants to budget for, especially when the immediate billable pressure is the next deliverable.
The honest move for most firms isn’t to retroactively make the legacy piles AI-ready. It’s to start fresh on new projects: clean schemas from day one, the why captured while it’s still in someone’s head, structured field capture instead of clipboards in questionable light. The legacy work shrinks as a percentage of the total over time, without anyone heroically trying to fix the past. The institutional knowledge, though, isn’t going to wait; that one has to be solved while the people still in the building know it. And it isn’t only the AI that gets stuck: the PM who inherits the project without all the information properly stored and accessible is just as screwed.
Peer firms further along the curve are quietly talking less about “adopting AI” and more about data engineering capacity. They’ve worked out that the AI conversation is downstream of a much less exciting one.
Three Pragmatic Moves
For a mid-sized firm not in a position to fund firm-wide data engineering yet, three things are still available.
First, pilot on a project where the structured pile is already clean. A long-running monitoring site, a site with a solid and maintained CSM, a job where the analytical data has been kept in a consistent schema. You won’t learn what AI can do at firm scale. You’ll learn what it can do on a single workflow under realistic conditions. That’s the more useful learning anyway.
Second, capture the why while you’re making the decision, not retrospectively. Tacit knowledge becomes documented knowledge through habit, not through projects. Two lines in the project log when you decide to exclude a well. A short note when the client asks for a scope tweak at the briefing. This isn’t an AI problem. Institutional knowledge has been walking out the door in our industry since long before AI; AI is just the first technology that puts a real price on it.
Third, treat AI as a verification multiplier, not a drafting accelerator. The useful pattern: give the AI direct access to the actual source document (the NEPM or ANZG guideline, the lab method standard, the regulatory letter, your own historical report), and ask it to find and quote what’s relevant. Primary source here means literally that. The AI reads the document in front of it; it doesn’t recall from its training. The risky pattern is the opposite, asking the AI to generate facts from memory. The first multiplies expert judgement. The second undermines it.
Where This Goes Next
The conversation with Bec was supposed to produce six general tips. What it produced instead was a suspicion that the general tips weren’t the article our readers needed. The next pieces in this short series will pick up the threads this one only gestured at: what modern AI actually is in 2026 versus what most policy still assumes; who is writing the rules that will shape AI use in our industry, and in what order; and what good practice looks like on a real project, verification chains and all.
The most interesting AI work in our industry isn’t happening at the firms with the biggest AI budgets. It’s happening at the firms with the cleanest data and the discipline to write down the why.
Sven Hoffmann is a founding member of the ALGA SIG-AI.