How does DeepInspect inspect the generated marketing draft when the model output is unstructured text?

The inspection layer reads the model output at the HTTP boundary before the output reaches the marketing tool. The classifier passes over the response body and tags any regulated claim surfaces the variants contain. The policy evaluates the tagged claims against the approved-claim library the brand maintains. The decision outcome attaches to the audit record. The mechanism is the same whether the model emits ten ad variants, a single landing-page hero, or a long-form blog draft.

Does the inspection layer replace our existing brand approval workflow?

The inspection layer is request-time. Brand approval is a separate human review stage. The inspection layer trims the brand-asset scope the LLM sees and inspects the regulated-claim content of the generated drafts. The brand approval workflow reviews the marketer's selected variant for tone, fit, and final sign-off. The two compose: the inspection layer enforces what the LLM is allowed to draft against, the approval workflow gates what ships to the channel.

What does the audit record look like for a marketing campaign that runs across three regions?

The record series captures one record per request, with the campaign identifier, the region the variant targets, the regulated-claim classification, and the policy version that evaluated the request. A campaign that draft-loops 200 variants across EU, US, and UK produces 200 records on the campaign identifier, each tagged with the region the variant served. The regulator reads the records on the per-region basis their jurisdiction covers.

How does the layer handle a marketing copilot built on top of a proprietary in-house model?

The inspection layer sits at the HTTP request boundary between the marketing tool and the model endpoint. The endpoint can be OpenAI, Anthropic, an Azure-hosted GPT, a Bedrock-hosted Claude, or an internal model served through a Triton or vLLM endpoint. The layer reads the request and response at the TLS termination, evaluates policy on the request content, and commits the audit record. The endpoint vendor does not affect the inspection mechanism.

AI Security for Marketing Content: The Inspection Layer Between the Drafting Prompt and the Brand-Approved Output

Marketing teams have moved a meaningful share of campaign drafting, ad variant generation, and landing-page hero copy onto LLM workflows. The marketer opens a chat interface, drops in the campaign brief, attaches the brand voice doc, and asks for ten ad variants for a Meta campaign. The model emits drafts. The marketer pastes the strongest variant into the ad manager. The cycle takes minutes per asset, runs across every channel the team owns, and reaches into customer data the workflow uses to ground the copy.

I want to walk through the four classes of data the marketing LLM workflow reads at request time, the identity-aware policy decisions the deployment commits at the brief-to-draft boundary, the audit record format that satisfies EU AI Act Article 12 for any marketing claim a high-risk system surfaces, and the architectural pattern that closes the gap most content-generation pipelines leave open today.

The data the marketing workflow reads at request time

The marketing LLM workflow reads four classes of data at each turn. The session identity carries the natural-person identifier from the SSO, the marketer's team and role, the brand the marketer is authorized to draft for, and the channels the marketer's role can publish into. The request content carries the brief, the campaign metadata (region, segment, offer), the system prompt the marketing tool sets, the model selection, and the retrieved brand guidelines. The retrieved context carries the brand voice doc, the approved claim library, regulated-claim restrictions per region (FTC, ASA, ACCC), and any customer-segment data the brief grounds against. The result content carries the generated draft variants, the trace of which brand-claim sources the model referenced, and any segment-level personalization the variants apply.

The four classes compose the decision surface the policy evaluates against. A marketer on the financial-services account can ask the same prompt that a marketer on the consumer-electronics account can ask, and the policy outcome differs because the FS account requires regulated-claim review and the consumer account does not. The identity-aware policy reads the specific combination at the specific moment.

The identity-aware policy decisions the deployment commits

The deployment commits five decisions at the brief-to-draft boundary before the draft reaches the marketer, and a sixth before the draft reaches the publish endpoint.

The first decision is brief classification. The classifier reads the marketer's brief and tags the regulated-claim surfaces it reaches: health claims, financial claims, comparative claims, environmental claims, and audience-targeting claims that touch protected categories. The classification result drives the next four decisions.

The second decision is brand-asset scope. The brand voice retrieval reads from an asset catalog. The policy evaluates the marketer's role against the catalog and trims the retrieved assets to the brand the marketer is authorized to draft for. A marketer working on the consumer brand sees only the consumer-brand voice doc, even if the FS-brand voice doc lives in the same catalog.

The third decision is claim inspection on the generated draft. The classifier reads each variant the model emitted and verifies that any health claim, financial claim, or environmental claim matches a pre-approved source in the claim library. A variant that makes a "lowest rate" claim outside the approved-claim set produces a redact or block decision before the variant reaches the marketer.

The fourth decision is the targeting check. The brief specifies the audience segment the campaign targets. The policy reads the segment metadata and verifies the targeting is permitted in the regions the campaign covers. A segment that targets a protected category in a jurisdiction where that targeting is restricted produces a block decision at this boundary.

The fifth decision is the regulated-region routing. EU campaigns route the drafts through the EU-resident inference deployment, the US campaigns route through the US deployment, and the regional segmentation flows on the audit record.

The sixth decision sits at the publish endpoint. The approved variant carries a policy-evaluated tag through to the ad manager, the CMS, or the email tool. The publish endpoint reads the tag, verifies the route the variant was approved for matches the channel the marketer is publishing to, and commits the publish record to the audit series.

The audit record the workflow has to produce

EU AI Act Article 12 takes effect August 2, 2026 for high-risk systems and requires automatic event recording over the system lifetime, identification of the natural persons involved, and retention for at least six months. Marketing systems become high-risk under the Act when they surface claims that influence credit, insurance, employment, or essential-service access. UK Advertising Standards Authority and US FTC rules apply to the generated claim itself. NIST AI RMF MANAGE 1.3 requires evidence that AI risks are tracked across the system lifecycle.

The audit record format carries seven fields regardless of which regulation surfaces the request. The record carries the natural-person identifier the marketer authenticated with, the campaign identifier, the brief-to-draft route, the regulated-claim classification the brief and draft carried, the policy version that evaluated the request, the decision outcome (allow, modify, redact, or block), the upstream model and version, and the integrity metadata that proves the record was not altered after the fact.

The record series satisfies EU AI Act Article 12, FTC §5 truth-in-advertising, UK ASA CAP code, NIST AI RMF MANAGE 1.3, and ISO 42001 record-keeping obligations from the same pipeline.

The architectural pattern that closes the gap

The pattern places an inspection layer between the marketing tool and the LLM endpoint, and a second inspection layer between the approved-draft handoff and the publish endpoint. Both layers read the marketer's identity from the propagated SSO context. The first layer evaluates the brief-classification, brand-asset-trim, claim-inspection, and targeting decisions. The second layer evaluates the publish-channel route check. Both layers commit per-decision audit records to a tamper-evident store.

The inspection layers are stateless. They evaluate each request against the marketer's identity, the policy version of record, and the data the request carries. The marketing tool keeps its own application logs for campaign operations. The two record series compose: the application records cover campaign state, the inspection records cover the regulated-claim obligations.

DeepInspect

DeepInspect is the inspection layer for that gap. The product terminates the AI provider TLS, reads the brief and the generated drafts at request time, evaluates identity-bound policy that knows the marketer's role and the brand the marketer is authorized to draft for, applies the regulated-claim, brand-asset, targeting, and channel-routing decisions, and commits per-decision audit records to a tamper-evident store with hash chaining across records.

The product runs as a stateless proxy on the marketer's existing chat tool, the brand workflow tool, or the in-house marketing copilot. Round-trip overhead measures under 50 ms in production, which is below the threshold the marketer notices against the 800 ms to 3 seconds of LLM response time per turn.

If your marketing team is drafting through LLMs and you owe an EU AI Act Article 12 record series by August 2, 2026, let's talk today.