The Function That Knows the Least

Somewhere this quarter, someone on your team asked an engineer to reconstruct, from memory, a decision that shipped eight months ago. The full record of that decision existed the entire time: the Slack thread, the ticket, the PR. Your team just had no way to stand in front of it.

GRC has always been the function that knows the least about the work it governs.

Every ritual we inherited is a coping mechanism for exactly that. Sampling, attestations, questionnaires, evidence collection: workarounds for a structural condition where your certification covers 100% while your auditor checked 0.07%, because the work was never observable to us.

That structural condition just ended. And almost nobody in GRC has clocked it.

Everyone Works Through a Harness Now

I actually watch it happen every day at Lovable.

The PM ships a feature by describing it. Legal reviews the DPA in the same interface. Finance builds the model there too. Support drafts responses, marketing drafts campaigns, and I build control checks, all through the same class of tool: an AI harness that sits between the person and their work.

And that harness is quietly centralising everything. MCP connectors pull Slack, Linear, Notion, Google Docs, meeting transcripts, and GitHub into one context window. Knowledge work that used to be scattered across ten opaque surfaces now compresses into a single observable pipeline:

Every unit of work through the harness leaves the same trace: what was asked, what was done, what came out. Prompt, action, outcome.

For engineering work, this legibility is old news. Git and CI made code queryable years ago, which is exactly why GRC Engineering worked there first. What's new is that the marketer's work, the lawyer's work, and the analyst's work are starting to produce the same engineering-grade artifacts, on standardised surfaces, with version history.

The Inversion

The thesis of this issue, and of the three-part series it opens:

For the first time in the history of this discipline, GRC can ingest more context than the work it governs produces. The context deficit flipped sign.

We spent decades starving. We are about to be drowning. And while everyone argued about whether AI should write your policies, AI became the surface your organisation works on. The debate was about the wrong layer.

One Substrate, Two Modes

What do you actually do with an observable pipeline? Two things, and they run off the same substrate.

Read is the promise your GRC platform's dashboard made and never kept. What if compliance was just a query on data you already collect? That question stops being rhetorical when the data is the work itself. Risk advice grounded in the actual Linear tickets and the actual Slack decision thread beats risk advice grounded in a workshop recollection, every single time.

Write is shift-left, which you've watched security engineering do for a decade, finally applied to all knowledge work. A guardrail at the juncture looks something like this:

# A guardrail, not a gate.
# Fires at the moment of work, not at the quarterly review.
control: customer-data-sharing
trigger:
  tool_call: send_external_email | share_document
  data_classification: customer
action:
  require: dpa-verification
  before: execution
evidence:
  emitted: automatically, as the trace of this rule firing

Notice what happened in that last block. Nobody collected evidence. The control firing is the evidence. This is policy-FROM-code arriving through the back door: the pipeline generates the record as a side effect of the work, instead of GRC reconstructing it after the fact.

And notice what the trigger is not: a classifier guessing at intent. Tool calls are discrete events the harness already mediates, which means the guardrail matches on something deterministic. Probabilistic intent-matching is the frontier; tool-call junctures are what you can build this quarter.

Where Your Org Actually Is: The Centralisation Ladder

At this point you might reasonably object that your company is nowhere near this. Correct. Almost nobody is at the end state. That's why the useful tool is a ladder, not a vision statement.

Find your rung. The point of the ladder is that your next 12 months of GRC work looks completely different depending on where you stand, and each rung has a concrete job.

• Stage 1 needs an acceptable-use decision, not a control framework.

• Stage 2 needs you in vendor negotiations asking for trace access. Concretely: in your next copilot security review, ask for audit-log API access that covers prompts and actions rather than just logins, retention terms for those traces, and an export format you can actually query. That's a maturity conversation, and your procurement team is not having it for you.

• Stage 3 is where control design starts mattering more than evidence collection.

• Stage 4 is where most of this issue lives.

Most of you are at stage 2. That's fine. The teams that understand the ladder at stage 2 will run the guardrails at stage 4. The teams that don't will get handed someone else's.

The New Scarcity

The inversion forces an uncomfortable trade: evidence-scarcity dies, and signal-scarcity replaces it.

The scarce skill in GRC used to be collection: getting the screenshot, chasing the attestation, extracting the log. The scarce skill now is selection: knowing which trace matters and where the guardrail goes. Signal versus noise stops being a mental model for prioritisation and becomes the entire job description.

And there's a trap waiting. Ingesting everything is the 2026 edition of the evidence binder. A team drowning in context that acts on none of it has rebuilt compliance theatre with better plumbing.

So when someone offers you a new trace, a new integration, a new data source, run it through three questions:

1. Which decision does this trace inform?

2. Which control could fire on it?

3. What does it let us stop collecting?

If all three come back empty, you aren't building capability, you're hoarding context.

The Precondition (Read This Before You Get Excited)

None of this works if the harness is a side tab.

Architecture before automation applies here with full force: the harness must actually be where the work happens, or the pipeline leaks. If the real decision was made in a hallway and the harness only saw the write-up, you're back to sampling theatre with a nicer dashboard. The trace is only as honest as the fraction of work that flows through it.

Watch for it in every vendor pitch this year: a partial pipeline presented as a full one. A guardrail on 30% of the work is a decoration, and you already know what decorative controls cost.

One more consequence of an observable pipeline, which I'll leave here deliberately: once the work is a trace, an unannounced control-failure experiment is just a query you haven't run yet. Hold that thought for a future issue.

The Context Problem Just Inverted

GRC's defining constraint, for the entire life of the discipline, was that we couldn't see the work. Every practice you inherited assumes that constraint. It no longer holds.

This issue is the anchor of a three-part series, because the inversion breaks more than evidence collection:

• Next issue: when agents update every surface as they work, where does truth actually live? (Spoiler: your source of truth is becoming a log, not a document.)

• After that: what GRC can now test that it never could, and why the controls sampling was invented for are the ones about to become continuously testable.

The context deficit was never the tragedy of GRC. It was the excuse. Now it's gone.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!