Extend the existing Claude PII policy unchanged to the new AI systems - and settle that HubSpot data is not restricted customer data

August 18, 2026 at 6:10 PMtechnicalmedium

Situation

Brady Dibble raised a data-access question about additional AI systems on 2026-08-15, treating the data he had lost access to as uniformly restricted. Peter refused to answer it per-system. He ruled that (1) the things you lost are not all the same - some are restricted and some are not, (2) Hubspot data is not customer data, and a list of customers is just fine while PII is not, (3) as far as I am concerned the same rules can apply to the two systems you just listed, and (4) there should be no barrier to moving approved data to them, but they should not open the door to more data than we currently allow to Claude. He pointed Brady at the existing policy, noting Michelle has it.

Reasoning

Peter converted a per-system approval request into a classification question. The policy already existed and the categories already existed - the only genuinely unclear fact was whether HubSpot counts as customer data, so he settled that single fact and let the existing rule do the rest of the work. Writing a second policy per tool would fork the hygiene he had just established, so instead he set parity with the Claude envelope as the default: new systems inherit exactly what Claude already has, no more. This is the same instinct as the 2026-08-11 inspectable-function ruling - establish one durable piece of hygiene and explicitly refuse to let it expand or fragment.

Additional Context

Confirmed by Peter. The operative constraint is parity with the already-approved surface rather than a fresh approval, and the CTO is not the per-system approver - the policy is.

Observed Evidence

Five consecutive direct quotes in a single DM exchange on 2026-08-15, moving from diagnosing the confusion (the things you lost are not all the same) to the classification ruling (Hubspot is not customer data) to the scope constraint (parity with the Claude envelope).

Matching Patterns

45%
Constrain the Mechanism, Not the Access(technical category, AI data access keywords, constrains mechanism rather than granting per-request access)

Confidence Breakdown

32/35
Evidence
25/30
Pattern
19/20
Source
7/15
Corroboration

Reasoning Depth Analysis

Org Signal:The policy is the policy. New AI tools do not get bespoke CTO rulings, and routing a per-system approval to Peter is not the path - reading the existing policy is.
Who Affected:Michelle Novicio as policy owner, RevOps and anyone working with HubSpot data, and every future AI tool adoption at CIQ which now inherits this default.
Precedent:Any new AI system inherits the Claude data envelope by default. Parity rather than case-by-case negotiation, and CRM contact lists are explicitly outside the restricted category while PII stays inside it.
Consequences:Real and immediate - it unblocked data movement to those systems the same day rather than pending a policy revision.
Timing:Now because Brady was blocked and over-restricting himself; the classification ambiguity was costing real work while the underlying policy already had the answer.

Source

reflection

AI Confidence

83%

Related Context

💬
DM with Brady Dibble

slack

Hubspot data is not customer data.

💬
DM with Brady Dibble

slack

So perhaps we need to be super clear about what we are talking about here. We should not be sending PII out the door. But a list of customers is just fine.

💬
DM with Brady Dibble

slack

As far as I am concerned the same rules can apply to the two systems you just listed.

💬
DM with Brady Dibble

slack

There should be no barrier to moving approved data to them. But they should not open the door to more data than we currently allow to Claude.

Outcome

No outcome recorded yet.

Decision ID: a30e5ee1-5fa0-49e0-92b0-c36bf4389a3a