Copper Feed

Author: copperfeed

  • How to Budget for Usage-Based Pricing

    Most writing about usage-based pricing is aimed at the companies selling it. Metering platforms, billing infrastructure, advice on migrating your pricing model. Very little is written for the person who has to put a number in next year’s budget for something with no fixed price.

    This is that. It assumes you did not choose this model and cannot opt out of it.

    Why the usual budgeting approach fails

    A seat-based line item is trivial to forecast. Headcount times rate, adjusted for growth. You could do it on a napkin and be close.

    Usage is not distributed like headcount. It is distributed like a power law, and this is the single fact that breaks most forecasts.

    Within the same plan tier, individual consumption commonly varies by more than an order of magnitude. Your median user is not your average user, and your average is dragged around by a handful of heavy ones. Budget from the median and you will be wrong by a multiple. Budget from the mean without knowing its shape and you will still be wrong, because the mean is unstable when the tail moves.

    The practical consequence: a pilot with ten people tells you very little about a rollout to two hundred, unless you looked at the distribution rather than the total.

    Build the forecast from the tail

    Run a pilot long enough to see a full work cycle, then throw away the average.

    What you want is per-user consumption sorted highest to lowest. Look at your top decile, because they are the ones who will define your bill, and look at what makes them different. Frequently it is a role rather than a personality: the people doing the work the tool is genuinely good at will use it constantly, and they are the reason you bought it.

    Then forecast three numbers rather than one. What it costs if usage looks like the pilot. What it costs if the heavy decile becomes a quarter of the org as the tool catches on, which is the realistic case for anything useful. And what it costs at the ceiling, which is the number your CFO will ask for and the one nobody prepares.

    Present all three. A single figure implies a confidence the model does not support, and you will own that number when it is wrong.

    Where the surprises come from

    Rarely from people using the tool more. Usually from something changing underneath.

    • A model swap. The vendor routes to a newer, larger model. Your behaviour is identical and your consumption is not.
    • A feature that quietly costs more. Agentic workflows, background jobs and long-context features consume dramatically more than chat, and they usually launch as an improvement rather than as a price change.
    • Automation. Something gets wired into a pipeline and starts running without a human triggering it. The bill stops being a function of headcount, and no seat-based instinct catches it.
    • The conversion rate. If your contract lets the vendor change what a credit buys, they can raise your price without touching a published figure.

    Only the third of those is under your control, which is why the contract questions matter more here than in any seat-based deal.

    Controls worth having

    In descending order of how much they help.

    1. A hard cap you administer. Not a notification. A ceiling where spend stops. Vendors do not offer this readily and it is the most valuable thing you can negotiate.
    2. Per-user or per-team limits. Turns one uncapped organisational exposure into many small bounded ones, and it puts the decision next to the person who understands the work.
    3. Alerts at 50, 75 and 90%. Standard advice, worth doing, and weaker than it sounds. An alert tells you the money is already gone.
    4. A monthly actuals review for the first quarter. Boring and effective. Most overruns are visible for weeks before anyone looks.

    The negotiation is different too

    Discount percentages matter less than they do on a subscription, because the discount applies to a quantity nobody has agreed on. What matters is the floor, the ceiling and who controls the rate.

    Push for a committed spend with a rate that improves at volume rather than a large allotment you may not use. Push for unused capacity to roll. And get a written commitment that the conversion rate is fixed for the term, which is the clause that decides whether your forecast means anything at all.

    If a vendor will not fix the rate, that is not a detail to concede late in a negotiation. It is the price being variable at their discretion, and it should change what you are willing to commit.

    What credits are and how to read them is in AI Credits Explained. The structural shift behind all of this is in The End of Per-Seat Pricing. CopperFeed records billing model changes as they happen, including the ones that arrive without an announcement.

    General guidance, not procurement or financial advice. Contract terms vary and yours govern.

  • AI Credits Explained: What You Are Actually Buying

    AI credits are the unit almost every enterprise vendor invented in 2026 to charge you for AI features. You buy an allotment, your usage draws it down, and when it runs out you either stop or start paying overages.

    The pitch is that credits give you predictability. What they mostly give you is a currency you cannot price, cannot compare, and cannot forecast.

    Every vendor minted its own money

    SAP has AI Units. Oracle has AI Units, which are not SAP’s. Microsoft has Copilot Credits and ACUs. Workday has Flex Credits. ServiceNow meters Assist consumption, AWS has Bedrock AgentCore, Google has Agent Engine.

    None of them are comparable. Each meters differently, converts differently, and expires under different rules. A credit is not a unit of anything. It is a private currency issued by the company selling you the goods, at an exchange rate it sets and can change.

    That is the part worth sitting with before you evaluate any of it on price. You are not comparing rates. You are comparing seven currencies against a basket of goods nobody has itemised.

    What a credit is actually pegged to

    Usually tokens, sometimes actions, occasionally both, and the conversion is frequently unpublished.

    Tokens are the underlying unit of model usage: text going in, text coming out, plus cached context. Most buyers have no intuition for how many tokens a task consumes, which is the root of the problem. Nobody can estimate an annual spend denominated in a unit they cannot picture.

    Vendors are candid about this in places. Abacus AI states plainly that its credits are not tokens and that it does not publish exact per-model credit rates, because the rates keep changing. That is honest, and it also means the price of the thing you are buying is not knowable at the time you buy it.

    Where a vendor does publish, read carefully for three things: whether cached and input tokens are billed at the same rate as output, whether credits expire monthly or roll over, and whether the model you actually use is priced differently from the default one in the marketing table.

    The bills that made this famous

    Zylo’s 2026 SaaS Management Index surveyed 218 IT leaders and found 78% had hit unexpected charges tied to AI or consumption in the past year. Not a fringe experience. The majority.

    The GitHub Copilot transition on 1 June 2026 is the case study, because it was well signposted and still went badly for heavy users. GitHub replaced premium request units with AI Credits metered on token usage, and held base plan pricing exactly where it was. Reporting since has described individual bills rising as much as sixtyfold, from $29 to around $750 and from $50 to roughly $3,000. Uber is reported to have exhausted its 2026 AI coding budget by April.

    Those individual figures come from secondary coverage rather than from GitHub, so treat the multiple as illustrative. The direction is not in dispute, and the mechanism is the point: the plan price did not change at all. The plan price was never where the money was.

    Why credits exist

    Not villainy. Inference costs real money per use, inside a business model built on near-zero marginal cost, and a flat subscription over variable cost is a losing trade for the vendor when usage is unbounded.

    Credits solve a genuine problem. They also happen to solve several others in the vendor’s favour: revenue that grows without a renegotiation, a price that can be changed by adjusting a conversion rate rather than a published number, and breakage on unused allotments. A mechanism can be both necessary and asymmetric.

    What to ask before you sign

    1. What is the conversion rate, in writing, and can you change it during our term? The single most important question, and the one most likely to get a vague answer. A rate the vendor can move unilaterally is a price they can raise without telling you.
    2. Do unused credits roll over or expire? Monthly expiry means you are buying peak capacity every month and discarding the difference.
    3. What happens at zero? Hard stop, automatic overage, or a call from your account manager. Each has a very different failure mode, and the hard stop is not always the worst one.
    4. Can we cap it? A hard ceiling you control, not an alert. Alerts arrive after the money is spent.
    5. What does a typical week cost for one heavy user? Make them model it. If they will not, that tells you they cannot, which tells you something about your own forecast.

    Instrument it before you need to

    Whatever you agree, assume the first two months of actuals will surprise you, and set alerts at 50%, 75% and 90% of the allotment so you find out while there is still time to change behaviour.

    Then watch for the change nobody announces. Conversion rates move, allotments get restructured, and a model swap in the background can change your consumption without any decision on your side. That is what CopperFeed records: dated entries for repricings and billing model changes as they land.

    Related: How to Budget for Usage-Based Pricing, and The End of Per-Seat Pricing.

    Figures here come from published research and reporting, attributed inline. Individual bill increases are drawn from secondary coverage and not confirmed by the vendors involved. Verify current terms before acting on any of it.

  • Oracle License Audits: What Makes Them Different

    An Oracle license audit is not a harder version of a Microsoft one. It is a different exercise, and the differences are structural rather than cultural.

    Most general audit advice still applies. What follows is the part that does not transfer.

    The soft audit

    Oracle frequently opens without invoking the audit clause at all. What arrives instead is an offer: a “license review”, a health check, an advisory conversation, sometimes free, usually framed as helpful.

    Because no clause was invoked, no contractual deadline applies and no formal scope exists. That sounds like an advantage and works as the opposite. A formal audit is bounded by what your agreement permits. An informal review is bounded by whatever you agree to hand over, and people hand over far more when nobody has said the word audit.

    Treat a review request with exactly the seriousness of a formal notification. Same single point of contact, same scope discipline, same review of anything before it leaves.

    Virtualisation is the main event

    The single largest source of Oracle claims, and the one where the gap between vendor position and contract text is widest.

    The dispute is about what counts as the machine your software runs on. Oracle’s stated position on soft partitioning means a database on a small number of virtual machines can be treated as licensable across a much larger pool of physical hosts it could theoretically move to. The multiplier this produces is how a modest deployment becomes a very large claim.

    The critical detail: Oracle’s partitioning policy is a published document, not a contract term, and it is generally not incorporated into the agreements customers sign. That distinction is the entire basis of most successful defences, and it is why the argument is worth having rather than conceding.

    None of which helps if your environment is genuinely wide open. Cluster design decisions made years ago by people with no licensing context are the usual root cause, and they are expensive to unwind under time pressure.

    Java is now a licensing problem

    The change that caught the most organisations out. Oracle moved Java SE onto an employee-based metric, so the price is driven by total headcount rather than by installs or by the people who use it.

    Read that again if you run Java anywhere. A handful of installations at a company of several thousand people prices against several thousand people. Organisations that considered Java a free runtime discovered they were buying a company-wide subscription.

    Java also spreads without anyone deciding to deploy it. It arrives bundled inside other vendors’ products, on developer laptops, inside container images. An inventory built from procurement records will miss almost all of it.

    Back-support is the sting

    Where an Oracle settlement diverges hardest from other vendors.

    A finding is rarely just the licence you should have bought. It is that licence, plus support fees backdated across the period you were non-compliant, at list. On a multi-year gap the backdated support can exceed the licence cost, and it is the line most people have not budgeted for when they estimate exposure.

    What to do differently

    1. Never run the scripts and send raw output. True everywhere, load-bearing here, because Oracle’s tooling reports on an estate far wider than your deployment and the interpretation gap is enormous.
    2. Establish what your contract actually incorporates. Specifically whether policy documents form part of it. This one question determines the size of the virtualisation argument.
    3. Inventory Java separately, and everywhere. Not via procurement. Scan endpoints, images and third-party products.
    4. Get the architecture diagram right before anyone asks. Which hosts, which clusters, what can move where. The defence is almost always technical, and assembling it under a deadline is how concessions happen.
    5. Price back-support into any exposure estimate. Otherwise your number is wrong by more than the licence itself.

    The wider point

    Oracle’s Java move is the cleanest example of something we write about constantly. Nobody’s deployment changed. The metric changed, and thousands of organisations became non-compliant overnight without touching anything.

    You cannot defend against that with an internal inventory, because your inventory is accurate. What went stale is the rule it was measured against. Tracking those changes as they happen is what CopperFeed is for, and it is the same mechanism behind legacy plan sunsets.

    General mechanics are in Software License Audits, and the selection patterns in What Triggers a Software Audit.

    General guidance, not legal or licensing advice. Oracle’s policies and metrics change, and your own agreement governs rather than any summary of it. Verify current terms and take advice before responding to a review or audit request.

  • What Triggers a Software Audit

    Audits look random from the inside. They are not. Vendors run audit programmes as revenue operations, and the accounts they select share a small number of characteristics.

    Knowing the software audit triggers will not make you immune. It will tell you which quarter to be ready for, which is most of the benefit.

    The pattern behind selection

    An audit costs the vendor money and burns goodwill with a customer. They run it when the expected recovery justifies both, which means they are looking for accounts where a shortfall is likely and where the commercial relationship is already going the wrong way.

    Put another way: audits are aimed at customers who are spending less than they used to, or are about to.

    The triggers most often reported

    Your spend went down

    The clearest one. You cut seats at renewal, dropped a module, or let a product lapse. Revenue that was forecast has gone missing, and an audit is the fastest way to look for it somewhere else in your estate.

    This catches people out because the cut was legitimate. You genuinely stopped using the thing. The audit is not a punishment for that, it is an attempt to recover the number.

    You declined a migration

    Particularly to cloud. If the vendor’s strategy is moving customers onto a hosted product and you said no, you have become an account that needs a different route to the same revenue. Refusing a migration is one of the most consistently reported triggers there is.

    Your agreement is expiring

    Timing here is not coincidental. An audit finding that lands during a renewal negotiation is worth far more to the vendor than the same finding six months later, because the shortfall can be folded into a bigger forward commitment instead of settled in cash.

    If you receive a notification within a couple of quarters of a major renewal, assume the two are related and plan the negotiation as one conversation rather than two.

    You merged, acquired, or divested

    M&A creates genuine licensing complexity, and vendors know it. Most agreements restrict transferring licences to a new legal entity, and most integrations move software around long before anyone reads that clause. Divestitures are worse, because entitlements rarely split cleanly.

    You told them something

    The underrated one. Headcount announcements, a press release about a new data centre, a case study naming your architecture, a conference talk by one of your engineers, a job posting listing the exact versions you run. All of it is public, and all of it is read.

    Two things that raise your exposure quietly

    Virtualisation. The gap between the hardware a product runs on and the hardware it could theoretically run on is where a great many claims live. Policies here are frequently not contractual, which is a fight worth having but a fight nonetheless.

    Vendor-side changes you did not notice. Licensing metrics change. Products get repackaged, editions get merged, a metric moves from installs to employees. Your deployment did not move, but the ruler did.

    That last one is the reason we track vendor changes at CopperFeed. A pricing or packaging change you missed is an entitlement change you cannot see in your own inventory, and it will surface at the worst possible moment. Related: Legacy Plan Sunsets.

    What to do with this

    Not paranoia. Timing.

    1. Assume the quarter after any significant cut is your risky one. Do the internal reconciliation then, while nobody is asking for it.
    2. Reconcile before a renewal, not during. Knowing your own position ahead of the conversation is the whole game, and it is much cheaper before there is a claim on the table.
    3. Treat M&A as a licensing project. It will not be on anyone’s integration checklist, and it should be.
    4. Keep a file of what changed. Dated notes on metric changes, repackaging and tier retirements for your major vendors. When an auditor asserts your entitlement means something different from what you understood, that file is the argument.

    If a notification has already arrived, the mechanics are in Software License Audits: Why You Got Picked and What Happens Next. Oracle works differently enough to warrant its own page: Oracle License Audits.

    Triggers here are drawn from published practitioner and consultancy accounts rather than from vendor disclosure, since no vendor publishes its selection criteria. Treat them as informed pattern-matching. General guidance, not legal advice.

  • Software License Audits: Why You Got Picked and What Happens Next

    A software license audit is a vendor exercising a clause you already agreed to. Not an investigation, not an accusation, and not optional. Somewhere in the agreement your company signed is a right for the vendor to verify your deployment against what you bought, and one day they use it.

    The letter arrives from procurement or legal, rarely from your account manager, and it is polite. It asks for a call to discuss a “license review”. What happens over the following weeks is largely determined in the first fortnight, mostly by people who have never done this before.

    Read the numbers you are about to be shown with suspicion

    Search this topic and you will find large settlement averages: figures in the millions for Oracle and SAP, high six figures for Microsoft, usually presented without methodology.

    Check who publishes them. Almost every page ranking for audit terms is written by a firm that sells audit defence, and the number at the top is doing marketing work. That does not make the figures invented. It does mean they are drawn from the population that hired a defence firm, which is the subset with the worst exposure, and it means nobody publishing them has an incentive to say your situation is probably fine.

    The same applies to the case studies, where an eight-figure claim reduced to almost nothing is presented as typical. Selection bias is doing the heavy lifting. Firms publish the wins.

    What is reliably true is duller: most audits end in a purchase rather than a penalty, the purchase is usually smaller than the opening claim, and the size of the gap depends mostly on preparation.

    What actually happens

    The shape is consistent across vendors.

    Notification. A letter citing the audit clause, naming an audit firm, and proposing a kick-off. The clock in your contract starts here, and the deadlines are usually shorter than the work requires.

    Data collection. You are asked to run vendor-supplied scripts or complete deployment questionnaires. This is the stage that decides the outcome, and the one companies rush.

    Findings. The auditor produces a report showing a shortfall, priced at list. Not your negotiated rate. List.

    Settlement. The claim converts into a purchase, usually alongside a renewal, frequently with the shortfall discounted in exchange for a larger forward commitment. This is where the vendor gets what it actually wanted.

    That last point is worth sitting with. An audit is rarely about the penalty. It is a mechanism for opening a commercial conversation you were not planning to have, at a moment when your negotiating position is weak.

    The one thing that matters most

    Look at the script output before it leaves your building.

    Vendor discovery scripts produce raw data that requires interpretation, and the interpretation is not neutral. The same output can support very different conclusions depending on how deployment, entitlement and environment are read. Hand it over unreviewed and the vendor’s reading becomes the starting position, and every subsequent conversation is you arguing backwards from their number.

    Run the scripts. Read the output. Understand what it says about your estate before anyone else sees it. If it shows a genuine gap, you want to know that privately first, because it changes your strategy entirely.

    Consultancies in this space claim companies that verify first concede substantially less. Treat the multiple as marketing, but the direction is right and the reasoning is obvious.

    Things that make it worse

    • Answering quickly to seem cooperative. Speed is not a virtue here. The deadline in your contract is negotiable more often than people assume, and asking for time is normal.
    • Letting scope drift. The audit covers what the clause says it covers. Requests routinely extend beyond that, and nobody will stop them on your behalf.
    • Engineers talking directly to auditors. Not because anyone is dishonest, but because a helpful technical answer given without context becomes a finding. Route everything through one person.
    • Treating it as a technical exercise. It is a commercial negotiation that happens to involve inventory data.

    The connection to everything else

    Audits do not arrive at random, and the triggers correlate with exactly the contract events we write about elsewhere: spend declining, a plan being retired, a migration you declined, a renewal approaching. We cover that in What Triggers a Software Audit.

    There is also a quieter link. When a vendor retires the tier you were on, your entitlements change under you, and the version of the truth you have been tracking internally goes stale. A lot of audit exposure is not deliberate over-deployment. It is an inventory that stopped matching a product catalogue that moved. That is the subject of Legacy Plan Sunsets, and the reason CopperFeed records what changed and when.

    Oracle deserves separate treatment, because its audit practice differs from the rest in ways that matter: Oracle License Audits: What Makes Them Different.

    General guidance, not legal or licensing advice. Audit rights, deadlines and remedies are defined by your own agreements, which vary considerably. Read yours, and get advice before responding to a notification.

  • Writing a Shadow AI Policy That People Will Actually Follow

    Most shadow AI policy documents fail the same way. They are written to satisfy an auditor, they prohibit more than they permit, and the people they govern never read past the first paragraph. Six months later usage is unchanged and nobody mentions it, which the policy owner reads as compliance.

    A policy that works looks different, and it is shorter than you expect.

    Why the strict version backfires

    Blanket bans do not reduce AI usage. They relocate it.

    The employee who was using a summariser on their work laptop now uses it on their phone. You have lost the logs, lost the ability to steer them toward something safer, and added a reason for them to stay quiet when something goes wrong. You have made the actual risk worse while making the reported risk zero, which is the worst possible combination because it looks like success.

    Salesforce found 27% of employees have entered confidential data into public AI tools. Those people are not saboteurs. They are trying to finish something, and a rule that makes finishing it harder loses to the deadline every time.

    What to write instead

    Four things, and they fit on one page.

    1. A green list, published and easy to find

    Name the tools people can use without asking, and say what each is cleared for. Most policies lead with prohibitions and bury the permitted list in an appendix, or never write one at all, which leaves “ask IT” as the only sanctioned path. Nobody asks IT. They just use the thing.

    The green list is the single highest-leverage part of the document, because it is the only part that gives people somewhere to go.

    2. A data rule people can apply without a lawyer

    The classification scheme in your security policy is not usable at the moment someone is about to paste. Write the rule so it can be applied in the two seconds actually available.

    Something closer to: never paste customer data, credentials, source code, or anything from an unreleased financial or legal document into any AI tool that is not on the green list. Concrete nouns beat “confidential information”, because everyone believes their own work is fine.

    3. A fast path for anything new

    If approval takes three weeks, your policy is decorative. Someone will have used the tool, finished the project, and forgotten about it before your review meeting happens.

    Commit to a turnaround measured in days, publish it, and hold yourself to it. A five-day answer that is sometimes no beats a three-week answer that is usually yes, because only one of them is fast enough to be worth using.

    4. Amnesty, stated plainly

    You need to know what is already running, and people will only tell you if telling you is safe. Say in the policy that reporting existing use carries no consequence, then honour it the first time somebody tests you, which is when the policy is really written.

    One exception worth being explicit about: if data has already gone somewhere it should not, you need to hear that early, and the incentive has to point toward telling you fast rather than hoping nobody notices.

    The clause almost everyone leaves out

    Every policy above governs tools people go and adopt. Almost none govern the AI your existing vendors switch on inside products you already pay for, and that is now where most new AI processing appears.

    Nobody signed up. No approval was sought, because no human made a decision. Your green list is silent, since the product was already on it, cleared for something that was true last quarter.

    Two lines fix it. State that vendor-shipped AI features count as new tooling and are reviewed on the same footing. And name somebody responsible for watching release notes and changelogs for material changes to what your licensed software does with your data.

    That second line is the one nobody staffs, which is why it keeps happening. Tracking it is what CopperFeed is for.

    Keep it to a page

    Length is inversely correlated with compliance. A one-page document people can hold in their head beats a twelve-page one that is technically comprehensive and functionally invisible.

    Test it before you publish. Give the draft to three people who are not in security or legal, ask them what they are allowed to paste into ChatGPT this afternoon, and see whether they can answer without rereading it. If they cannot, the problem is the document.

    Then revisit it on a schedule, because the tools change faster than the policy will. Something on your green list this quarter may ship a feature next quarter that changes what it does with your data, and the review date is what catches that.

    Finding out what is already running comes first, and costs nothing: How to Find Shadow AI in Your Company Without Buying a Tool. The wider picture is in Shadow AI: The Tools Nobody Approved and Nobody Tracks.

    General guidance, not legal advice. Employment and privacy obligations vary by jurisdiction, and anything touching monitoring or discipline should go past your own counsel before it ships.

  • How to Find Shadow AI in Your Company Without Buying a Tool

    Most shadow AI detection advice ends with buying a platform. You do not need one to get started, and you should not buy one before you know the size of the problem, because the demo you sit through will be calibrated to whatever the vendor thinks scares you most.

    Everything below uses data you already have. A competent admin can work through it in an afternoon.

    Start with OAuth grants

    This is the highest-yield ten minutes available to you, and most teams have never looked.

    Every time someone clicks “Sign in with Google” or “Continue with Microsoft” on an AI tool, your identity provider records it, along with the scopes that app requested. Not just that the account exists, but what it was allowed to read.

    • Google Workspace: Admin console, Security, API controls, App access control. The third-party apps list is sortable by user count.
    • Microsoft Entra ID: Enterprise applications, filter to those you did not add, and check Permissions on anything unfamiliar.
    • Okta: the OAuth grants report under Reports.

    Sort by scope rather than by popularity. A tool 40 people signed into with basic profile access is a procurement question. A tool two people granted full mailbox read access to is today’s problem, and the count of users tells you nothing about which is which.

    Then read the expense reports

    Free tiers hide the initial adoption, but they are designed to convert, and conversion leaves a trail. Pull twelve months of card and reimbursement data and search descriptions for the obvious vendor names plus the generic ones: “AI”, “GPT”, “assistant”, “copilot”, “transcription”.

    Two patterns matter more than any single line. Look for the same vendor expensed by several people separately, which means a team standardised on something without telling anyone and you are paying retail per seat. And look for small recurring charges under whatever your approval threshold is, because that threshold is exactly where this behaviour lives.

    Look at what the network already knows

    You do not need packet inspection or a new appliance. DNS query logs answer the question well enough, and your resolver is already keeping them.

    Pull the last 30 days, aggregate by domain, and sort by unique internal clients rather than total volume. Volume finds the noisiest tool. Unique clients finds the one that quietly spread across a department, which is the thing you actually want to know about.

    If you run a proxy or an endpoint agent, the same query gets you application-level detail. If you have neither, DNS gets you most of the way for free.

    Check the browser

    The category people forget. Browser extensions with AI features hold permission to read and change data on every page the user visits, which in a browser-based company means every internal system you own.

    Both Chrome and Edge enterprise management report installed extensions across the fleet. Pull that list and look at the permissions column, not the names. An extension does not have to be an AI tool to be reading everything on your admin pages.

    Ask people, honestly

    The step technical teams skip, and frequently the most productive one.

    A short anonymous survey asking what people actually use, framed explicitly as inventory-taking rather than enforcement, will surface tools no log catches: things used on personal devices, things accessed on phones, things people would not have thought to mention.

    It only works if the framing is true. Ask which tools people use, promise nobody is in trouble, then discipline someone for an answer, and you have poisoned the well for every future exercise. If you cannot make that promise honestly, skip this step rather than run it dishonestly.

    The part everyone misses

    Everything so far finds tools your people went out and adopted. It will not find AI that arrived inside software you already own, and that is now the larger category.

    When a vendor ships an AI assistant into an existing product, there is no signup, no OAuth grant, no new domain, no expense line. Your inventory looks unchanged, because by every measure above, it is. What changed is what your existing tools now do with your data.

    Finding those means reading vendor changelogs and release notes for the software you already license, which is tedious and which almost nobody does consistently. It is also precisely what CopperFeed exists to record.

    What to do with the list

    Resist the urge to act on all of it. Sort into three piles.

    1. Fine. Most of it. A summariser with no data access used by one person is not a governance crisis, and treating it as one costs you credibility for the cases that matter.
    2. Consolidate. The four tools doing one job. This is where the money is, and it is an easy win because you are giving people a better-supported version of something they already chose.
    3. Deal with now. Anything holding customer data, source code, or credentials, and anything with broad OAuth scopes. Usually a short list, which is the good news.

    Then decide whether you need a platform. You will be negotiating from a position of knowing your own numbers, which is a different conversation from the one you would have had first.

    What to write once you have the list is in Writing a Shadow AI Policy That People Will Actually Follow. The wider picture is in Shadow AI: The Tools Nobody Approved and Nobody Tracks.

    General guidance, not security or legal advice. Check your own obligations before acting on any of it, particularly around monitoring employee activity, which is regulated differently depending on where your people are.

  • Shadow AI: The Tools Nobody Approved and Nobody Tracks

    Shadow AI is the AI tooling running inside your company that nobody approved. Not smuggled in by bad actors. Signed up for by a product manager on a Tuesday because it saved her an afternoon, paid on a personal card or not paid for at all, and never mentioned to anyone.

    It is the fastest-growing category of software in most organisations right now, and almost none of it appears on the spend report that finance reviews.

    How big is it really

    Bigger than most inventories suggest, though the honest answer is that nobody knows precisely, and the published numbers disagree with each other more than the coverage admits.

    Microsoft’s 2025 Work Trend Index found that 78% of people using AI at work are bringing their own tools, outside IT approval. Salesforce’s State of IT research put it lower, at 65% of employees using at least one AI tool their IT or security team has not sanctioned. Other vendor surveys in 2026 report figures as high as 98% of organisations. The spread is not a rounding error.

    The gap comes from definitions rather than from anyone being wrong. Does a browser extension count? A free ChatGPT account on a work laptop? An AI feature that a vendor switched on inside a tool you already licensed? That last one is doing a lot of work in these numbers, and it is the category nobody has a policy for, because nothing was installed and nobody signed up for anything.

    Treat any single shadow AI percentage you see as an argument rather than a measurement. What holds across all of them is the direction and the rough shape: most companies, most employees, growing fast.

    Why it is different from ordinary shadow IT

    Shadow IT is decades old and the playbook is well worn. Someone buys Dropbox, IT finds out, it gets consolidated. Annoying, bounded, solved.

    Three things make the AI version behave differently.

    The data leaves. A rogue project management tool holds your task list. A rogue AI tool holds whatever your employee pasted into it, and people paste a lot. Salesforce found 27% of employees have put confidential company data into public AI tools. That is not a permissions problem you can fix after the fact. The text is already gone, possibly into a training set, and there is no revoking it.

    It is free, so procurement never sees it. Shadow IT used to surface through expense reports, because software cost money. The free tier is the entire problem here. No invoice, no card charge, no renewal, no vendor record. Your spend management platform is structurally blind to it, and every dashboard you own will keep reporting that everything is fine.

    It arrives inside tools you already bought. The vendor ships an AI assistant into the product next quarter and it is on by default. Nobody adopted anything. Your approved software is now doing inference against your data under terms most buyers have not read since the original signature.

    What it actually costs

    Gartner’s 2025 research puts some numbers on this. Organisations without governance structures spend 2.5 times more on AI incident remediation than those with controls in place, and it projects shadow AI will cost enterprises more than $40 billion by 2027. Only 34% of organisations have a formal shadow AI detection program at all.

    Worth reading those with the usual caution, since analyst projections about emerging categories have a poor track record and the firms publishing them sell governance advice. The 34% figure is the interesting one anyway, because it is a measurement rather than a forecast, and it says two thirds of companies are not looking.

    The costs that land first are duller than a breach and more likely:

    • Duplicate spend you cannot see. Four teams on four AI writing tools, three of them free until the trial ends and someone expenses an upgrade.
    • Data in places your DPA does not cover. Which becomes a real problem the first time a customer asks where their data goes, or an auditor does.
    • Work that depends on an account nobody owns. The workflow runs on a tool registered to someone’s personal email. That person leaves. Nobody can log in.
    • Vendors that vanish. The AI tooling market is churning hard, and a free tool with no contract gives you no notice period and no data export commitment when it goes. See what happened to Lattice HRIS customers, and that was a paid product with eight months of notice.

    Why banning it does not work

    The instinct is a blanket prohibition. It fails, reliably, for a reason worth understanding before you try it.

    People adopt these tools because they work. Someone found a way to do a two-hour task in ten minutes, and a policy telling them to stop is a policy telling them to be slower at their job. What a ban produces is not less usage. It is the same usage on personal devices, where you have no visibility at all, and where the employee now has a reason not to tell you when something goes wrong.

    The organisations getting this right treat it as a supply problem. If people are reaching for unsanctioned tools, the sanctioned ones are missing, too slow to get approved, or nobody knows they exist. We cover what to write instead in Writing a Shadow AI Policy That People Will Actually Follow.

    Start by looking

    You cannot make decisions about an inventory you do not have, and the first pass costs nothing. Your SSO logs, OAuth grants, expense reports and DNS traffic already contain most of the answer, which is the subject of How to Find Shadow AI in Your Company Without Buying a Tool.

    What that exercise tends to surface is not a security horror story. It is a list of eleven tools doing four jobs, two of which you are paying for twice, and one of which is holding something it should not. That list is worth having before somebody else compiles it for you.

    CopperFeed tracks what changed in SaaS and AI tooling as it happens, including the AI features vendors switch on inside products you already own.

    Figures here come from published vendor and analyst research, attributed inline. Shadow AI statistics vary widely by definition and methodology, so treat any single number as indicative.

  • Lattice HRIS Has Shut Down. What To Do If You Missed the Deadline

    Lattice HRIS is gone. Not going, gone. Payroll access ended on 31 March 2026, HRIS access ended on 31 July, and reporting indicates customer data was permanently deleted on 6 August.

    Almost every guide you will find on this shutdown was written for people who still had time. If you are reading this in August 2026 or later, you do not, and the advice you need is different. This page covers what is actually still available.

    The timeline

    November 2025 Lattice announces it is discontinuing HRIS and payroll
    31 March 2026 Payroll access ends
    April 2026 A Rippling-formatted census export is added
    31 July 2026 HRIS access ends permanently
    6 August 2026 HRIS customer data reportedly deleted

    Roughly eight months of notice, which is more than plenty of vendors give. The sting is at the end of the list rather than the beginning.

    One sourcing note, because it matters here. The 6 August deletion date and the detail that Lattice’s standard 180-day retention window does not apply to HRIS customers come from a single published guide. We have not seen that confirmed in a Lattice notice we can link to. If your data matters, treat it as a strong signal to go and check rather than as settled fact, and ask Lattice directly.

    What did not shut down

    Worth being precise, because the headline confuses people. Lattice the company is fine. Lattice discontinued its HRIS and payroll products and is refocusing on performance management, and the Talent Suite (reviews, goals, OKRs, 1:1s, engagement surveys, compensation planning) carries on. Existing customers have been offered discounts on it.

    So if you use Lattice for performance reviews, nothing happened to you. If you used it as your system of record for people and pay, everything did.

    If you exported before 31 July

    Check what you actually got, because CSV exports are where this goes wrong quietly. The admin panel covered People, Time Off, Time Tracking, Goals, Updates, Engagement and Custom Reports. What tends to be thin or missing:

    • Uploaded documents. Signed offer letters, policy acknowledgements, visa and I-9 paperwork. These rarely come out in a row-per-employee CSV, and they are the ones you cannot recreate.
    • Historical effective dates. A current-state export gives you today’s salary and title. It does not always give you the compensation history behind them, which is what you need for pay equity analysis and for anyone asking about promotions three years ago.
    • Terminated employees. Exports frequently default to active staff. Your retention obligations do not.
    • Time-off balances mid-accrual. A balance is a calculation, not a fact. Check that the accrual rules came with the number.

    Open the files. Do not assume a download that completed is a download that is complete.

    If you did not export

    Do these in order, today.

    1. Contact Lattice support in writing and ask directly. Ask whether any copy of your data still exists, in any system, including backups, and ask them to answer in writing. A deletion date published in a third-party guide is not the same as a confirmed irreversible deletion of your tenant. This is a five-minute email and it is the only step that could recover everything.
    2. Reconstruct from the systems that were downstream of Lattice. This is where most of your data actually still lives. Your payroll provider holds pay history. Benefits carriers and your 401(k) administrator hold enrolment, dependants and deduction records. Your ATS holds hire dates and offer details. If anything was piped out over SFTP, the destination still has it. If you ran that Rippling census export in April, that file is a census.
    3. Check your own accounting system. Payroll journal entries in the general ledger will reconstruct compensation history further back than most people expect.
    4. Then worry about the new HRIS. Counterintuitive, but recovery is time-sensitive and vendor selection is not.

    The part nobody puts in the migration guides

    Losing payroll records is not only an operational problem. Employers in the US have statutory retention obligations: broadly, three years for payroll records under the FLSA and four years for employment tax records under IRS rules, with state requirements layered on top and longer clocks for some categories. Those obligations sit with you, not with the vendor who deleted the database.

    If you have gaps, that is a conversation to have with your employment counsel now rather than at your next audit. We are a change feed, not a law firm, and this is the point where you want a real one.

    Where people went instead

    CopperFeed does not rank tools, so this is a list rather than a recommendation. Vendors and coverage around this shutdown have most often pointed at HiBob, Rippling, BambooHR, Factorial, Calamari, HR Partner and MHR.

    Read all of it with the obvious caveat in mind: nearly every “Lattice is shutting down” guide currently ranking was published by a company selling a replacement. That does not make them wrong, and several are genuinely useful on export mechanics. It does mean the shortlist you are reading was assembled by someone on it.

    The lesson worth taking

    Lattice gave eight months of notice, which is not the failure here. The failure is that the data retention terms turned out to be worse than the standard policy customers assumed applied, and nobody discovers that until the shutdown notice lands.

    Two things to check in every vendor contract you hold, while this is fresh:

    • What is the post-termination data retention window, and does it apply to every product line? Lattice’s 180 days reportedly did not extend to HRIS customers. A retention promise in a master agreement can be undercut by a product-specific schedule.
    • What export format are you entitled to, in writing? “You can export your data” and “you can export your data in a form another system can ingest” are very different commitments, and only one of them helps at 3am in week ten of a migration.

    More on contract terms that survive this kind of event in Grandfathered SaaS Pricing Is Ending. The running list of retirements is in Legacy Plan Sunsets: Every SaaS Tier Being Retired in 2026.

    Dates and export details here come from published third-party reporting, linked inline, and had not been confirmed against a Lattice notice at the time of writing. If you know differently, tell us and we will correct it and say what changed.

  • Grandfathered SaaS Pricing Is Ending: How to Protect Your Rate

    Grandfathered SaaS pricing is the arrangement where existing customers keep paying an old rate after the vendor raises it for everybody else. It used to be indefinite by default. Loyal customers kept their price, sometimes for a decade, and nobody wrote it down because nobody had to.

    That default has flipped. The 2026 pattern is time-limited grandfathering: twelve to twenty-four months of protection, paired with feature gates so anything new belongs to the current tier. Your rate is safe. Your product slowly stops improving.

    Why vendors changed the deal

    Grandfathering used to be a marketing expense that retention paid for. A customer sitting on a five-year-old rate still threw off near-100% gross margin, so protecting them cost the vendor an opportunity rather than a dollar.

    AI broke that arithmetic. Inference is a real per-use cost, so a grandfathered customer who uses AI features can now cost the vendor actual money every month. Withholding those features forever is not an option either, because they are the roadmap, and a legacy tier that visibly falls behind churns on its own.

    So the industry landed on time-limited grandfathering with feature gates. Existing customers get a defined runway, any increase is tied to visible new capability, and, in the part that matters to you, a protection that used to have no expiry date now has one.

    The feature gate is the part people miss

    Most buyers hear “your price is protected” and stop listening right there. The gate is where the cost actually accrues.

    On a gated legacy tier your rate holds, but every new capability ships to the current tier instead. For a few months you will not notice. By month twelve your team is working around gaps that a competitor’s users do not have. By month eighteen the migration you turned down is one you are asking for, at whatever the price is by then, with no leverage at all, because you are the one who brought it up.

    That is the design. Time-limited grandfathering does not stop the increase. It schedules it, and arranges for you to request it.

    Whether that is a bad deal comes down to whether you use the gated features. A team that will never touch AI summarisation should take the gated legacy rate cheerfully and look again in a year. The mistake is accepting the gate without working out which side of that line you are on.

    Six questions to ask before you sign

    In writing, before renewal. Keep the answers.

    1. Is our current tier being retired, and on what date? The whole conversation in one question. A vendor who will not answer it by email has answered it.
    2. How long is the grandfathered rate guaranteed, and is that in the contract? “You’re fine for now” from an account manager who will have changed roles before your next renewal is not a commitment.
    3. Which features are gated to the current tier, and which of those are on the roadmap? The forward-looking half is the half that matters, and the half they would rather answer vaguely.
    4. What is the migration price, quoted today? Get the number while you can still do something with it. A migration quote at 120 days is a completely different document from the same quote at 20.
    5. Does our uplift cap survive a SKU change? Usually it does not. A cap governs renewal of a product, and a retired product cannot be renewed. Better to find that out now than in the quote. See Forced SKU Migration.
    6. If we migrate, is the new rate protected, and for how long? Routinely forgotten. Move to an AI tier with no cap and you are doing all of this again next year, from a higher base.

    Getting the protection into the contract

    Four clauses do most of the work. None of them are unusual asks.

    • A price-hold with an explicit end date. The rate and the term, in writing. Without this the rest is decoration.
    • A SKU-continuity clause. If the tier is discontinued mid-term, you migrate at an equivalent effective rate instead of at list. This is the clause that survives a forced migration, so it is the one to spend your negotiating capital on.
    • An uplift cap that applies across SKU changes. The wording carries real weight here. A cap on “renewal of the Services” is far stronger than a cap on “renewal of the Plan”.
    • A notice period on tier retirement. Ninety days minimum. Productiv gave four days’ notice on a full shutdown in August 2026, which is the argument for writing a number down rather than trusting the market norm.

    If you have already lost it

    Once the rate is gone, what is left are the moves that do not need the vendor to agree to anything. Reclaim unused seats, because most organisations are meaningfully over-licensed and a migration is the natural moment to audit. Consolidate overlapping tools, because AI bundling means you are probably paying twice for the same capability now. Trade term length for rate if you are staying regardless. And price one real alternative, not as a threat, just so you know.

    Watch it happen to someone else first

    Grandfathering usually ends for a vendor’s entire customer base at once, in a wave that starts months before it reaches your renewal date. Seeing the wave early is most of the advantage.

    CopperFeed records those changes as dated entries: launches, releases, repricings and shutdowns, in the order they happened. The running list of retirements is in Legacy Plan Sunsets: Every SaaS Tier Being Retired in 2026.

    Figures here come from published third-party reporting. General guidance, not legal or procurement advice. Contract language varies, and your own terms govern.