Tag: agentic AI

  • AI Risk Governance: An Operating Model for Cyber Defense

    AI Risk Governance: An Operating Model for Cyber Defense

    You may already have an AI roadmap, an approved model vendor, and several agent pilots. The harder decision comes next: when should an AI workflow be allowed to read customer data, call a connector, change a record, communicate externally, or touch production?

    A model that is acceptable for drafting internal content can become dangerous when its output triggers a business action. Your governance system therefore needs to answer a practical set of questions: What can happen, under whose identity, using which data, with what evidence, and how will you detect and stop the workflow when it behaves incorrectly?

    Govern the action, not only the model

    Model approval is necessary, but it is not the right boundary for operational risk. The unit you need to govern is the complete AI workflow:

    • A person, application, or event supplies an input.
    • The workflow retrieves business data or external content.
    • A model interprets that context and produces an output.
    • A connector or tool may turn the output into an action.
    • The result is shown to a user, written to a system, or used in another decision.
    • Prompts, feedback, outputs, and operational events may become part of a new data loop.

    Risk can enter at every step. A legitimate document can contain a malicious instruction. A correctly functioning model can receive more data than the user is authorized to see. A connector can possess broader permissions than the task requires. A plausible but false output can be harmless in a draft and costly when it changes a customer account.

    Your baseline threat model should also assume that attackers can use AI to personalize social engineering, imitate trusted voices, vary malicious code, and automate reconnaissance. A generic warning about suspicious emails is not enough when an employee may receive a credible message written for their role, account, and current project.

    Create an inventory entry for every workflow, not merely every model. Each entry should record:

    • Business purpose and owner: the outcome the workflow supports and the person accountable for it.
    • Inputs and data classes: what the workflow can receive, retrieve, infer, and retain, including personal or confidential information.
    • Model and provider: the model used, where inference occurs, and which vendor terms affect storage, training use, or residency.
    • Tools and connectors: every system the workflow can read from or write to.
    • Execution identity: the service account, user delegation, permissions, secrets, and authorization scopes involved.
    • Action class: whether the workflow observes, drafts, recommends, or executes.
    • Reversibility: how an incorrect action would be undone and which actions cannot be fully reversed.
    • Evaluation evidence: the legitimate and adversarial cases the workflow must pass before release.
    • Operational controls: logging, retention, approval, escalation, shutdown, and rollback mechanisms.
    • Consumption controls: usage caps, environment tags, latency limits, and cost per transaction.

    This inventory should function as a production registry, not a spreadsheet that is reviewed once and forgotten. Release checks should reject unregistered models, connectors, or identities. Runtime policy should deny capabilities that are not declared for the workflow. That is how you keep shadow AI and permission drift from quietly expanding the attack surface.

    Map the crown-jewel path before choosing controls

    Start with the business impact you cannot accept. Crown jewels are not limited to databases. They include data, identities, workflows, and systems whose compromise could materially harm customers, revenue, operations, or trust.

    1. Name the impact. Write a concrete failure statement such as exposing customer information, changing a production configuration, issuing an unauthorized credit, or sending a message under an executive’s identity.
    2. Trace the data path. Mark where information is collected, retrieved, transformed, sent for inference, displayed, logged, and reused as feedback.
    3. Mark every trust boundary. Include vendor APIs, plugins, browser sessions, retrieval indexes, queues, internal services, and external connectors.
    4. Assign an identity to each step. Avoid a shared, all-purpose agent credential. Give each component only the access required for its declared task.
    5. Locate the consequential action. Identify the exact point where generated content becomes a system change, customer communication, financial event, or security decision.
    6. Define the evidence trail. Decide what must be recorded so an investigator can reconstruct the input, authorization decision, tool call, approval, outcome, and rollback.

    Identity is the central enforcement point. Zero-trust principles apply to AI workflows just as they do to employees and services: verify each request, use least privilege, isolate secrets, and do not treat a successful login as permanent authorization. A user who may read a record should not automatically be able to authorize an agent to modify it.

    The vendor boundary needs equal attention. Record the applicable data-processing terms, control reports such as SOC 2 or ISO documentation, regional data-residency commitments, retention behavior, and whether submitted data may be used for training. A vendor review does not replace workflow controls; it tells you which risks remain yours to manage.

    Turn the map into threat scenarios that can be tested. At minimum, examine whether:

    • Malicious content retrieved from a document, ticket, web page, or message can redirect the model or trigger a tool.
    • Personal or confidential data can be copied into an unapproved prompt, output, log, or external destination.
    • A compromised dependency, model, plugin, or connector can alter the workflow’s behavior.
    • A fabricated or biased output can cross the action boundary without adequate review.
    • A convincing voice, message, or support interaction can persuade a person to bypass an approval control.
    • Overbroad permissions allow the workflow to act on records or systems outside its intended scope.
    • Missing telemetry prevents the security team from distinguishing normal automation from abuse.

    Each scenario needs an expected control outcome. The test is not complete because the team tried an attack prompt; it is complete when the team can show that the request was denied, the event was visible, the alert reached the right owner, and no prohibited action occurred.

    Do not red-team a production workflow if the test could expose real data, contact a customer, modify a record, or invoke a paid or destructive operation. Use a sandbox with synthetic or approved test data, isolated credentials, and disabled external side effects. Move the scenario toward production only after the containment controls have been demonstrated.

    Match autonomy to blast radius and reversibility

    Autonomy should be earned at the workflow level. The same model may support several autonomy levels because the consequence depends on the data, identity, tool, and action around it. The following control contract is a practical starting point rather than a universal compliance classification.

    Workflow modeFailure to design forMinimum control gateRelease evidence
    Read or generateSensitive input leakage, unsupported output, or inappropriate retentionApproved data classes, data minimization, access control, retention rules, grounded prompts, citations where available, and content filteringEvaluation on a maintained reference set, data-flow review, and inspectable logs
    Recommend to a personAn inaccurate or biased recommendation influences a consequential decisionAll read-and-generate controls, plus a named reviewer, visible supporting evidence, and no automatic executionError analysis by failure type, adversarial cases, and a record of reviewer acceptance, rejection, or correction
    Execute a reversible actionPrompt injection, excessive permissions, or invalid output causes an unauthorized changeScoped identity, tool allowlists, isolated secrets, egress restrictions, sandboxing, output validation, explicit confirmation, and a tested rollback pathRed-team results, authorization tests, complete audit events, and a successful rollback rehearsal
    Execute a high-impact or difficult-to-reverse actionCustomer, revenue, production, privacy, or trust is materially harmed before containmentExplicit approval at the final action boundary, staged execution where possible, granular scopes, usage limits, fail-closed behavior, a shutdown control, and a named incident ownerAdversarial evaluation, recovery evidence, approver training, and sign-off from the accountable risk owner

    Human-in-the-loop is not a sufficient control description. The reviewer needs enough information to make a real decision. At the approval boundary, show:

    • The exact proposed action and its target.
    • The data used to produce the recommendation and any destination that will receive data.
    • The tool, identity, and permissions that will be invoked.
    • The reason for the action and the supporting evidence or citations available.
    • Whether the action is reversible and what the rollback will do.
    • Any validation warning, policy exception, or unusual behavior detected upstream.

    Bind approval to one proposed action and let it expire when the underlying data, target, or parameters change. A person approving a preview should not unknowingly authorize a later, materially different tool call. For agentic systems, high-risk actions need explicit approvals, granular scopes, secrets isolation, egress controls, sandboxing, and validated outputs.

    Before increasing autonomy, define acceptance limits for the risks that matter in that workflow. These can include task quality, unsupported claims, biased outcomes, forbidden tool requests, abnormal data egress, false-positive alerts, latency, cost per transaction, and rollback success. Set the limits before the pilot produces attractive results. Otherwise, the release decision will move to accommodate whatever the demo happens to show.

    Use a maintained reference set for intended behavior and a separate adversarial set for abuse cases. Any test that produces an unauthorized action, forbidden data transfer, or privilege violation should block the release until the underlying control is corrected and retested. A strong average quality score cannot compensate for a security boundary that sometimes fails open.

    Operate AI defense as a product and incident loop

    Governance becomes useful when it changes runtime behavior. Policies need to control identities, data access, tool use, destinations, approvals, and resource consumption. Detection then needs enough context to distinguish expected automation from misuse.

    Build one defensive loop

    1. Prevent. Enforce data classification, least privilege, connector allowlists, egress restrictions, output validation, and action gates.
    2. Observe. Correlate AI events with identity, endpoint, application, and network telemetry.
    3. Decide. Route suspicious behavior to a person who can see the workflow context and business consequence.
    4. Contain. Revoke credentials, disable a connector, stop egress, suspend the workflow, or roll back a reversible action.
    5. Learn. Add the failure to the evaluation set, update the threat model, change the control, and prove the correction before restoring autonomy.

    Behavioral detection matters because an individually valid event may become suspicious only in context. Correlating identity signals with endpoint and network activity can expose subtle anomalies that static signatures miss. For an AI workflow, add model and tool events to that context.

    A useful audit event should identify the initiating actor, execution identity, workflow and model, prompt or template version, retrieved resource identifiers, tool requested, authorization result, validation result, human approval if required, resulting action, and rollback status. Record enough to reconstruct the incident without automatically storing every raw prompt. Indiscriminate prompt logging can create another repository of personal data, secrets, and confidential content, so apply minimization, access controls, redaction, and retention rules to the logs themselves.

    Your dashboard should combine security, model, product, and economic outcomes. Track:

    • Coverage: high-impact workflows with a named owner, current threat model, evaluation suite, and tested shutdown path.
    • Model quality: results by task and failure category, rather than one blended score that hides a dangerous edge case.
    • Control performance: denied tool calls, policy exceptions, privilege violations, suspicious egress, and approval overrides.
    • Response: signal-to-noise ratio, mean time to detect, mean time to contain, and recovery status.
    • Engineering quality: escaped defects, vulnerable dependencies, and security findings detected before release.
    • User outcome: task completion, reviewer burden, corrections, and abandonment at the approval step.
    • Economics: latency, usage by application and environment, and cost per transaction.

    AI can help inside the defensive loop without owning it. Security assistants can summarize incidents, connect related evidence, explain a probable cause, and propose next steps. That can reduce analyst toil and accelerate decisions. It should not silently convert a probabilistic recommendation into a destructive containment action. Apply the same autonomy and approval framework to defensive agents that you apply to customer-facing ones.

    Give product and security one backlog

    AI risk cannot be handed to security after the workflow is built. Product defines the intended outcome and unacceptable user harm. Engineering implements boundaries, telemetry, and rollback. Security owns threat modeling, control assurance, adversarial testing, and incident readiness. IT and identity owners govern accounts and connectors. Data and privacy owners determine permitted use, retention, and vendor conditions. The business owner accepts the residual operational risk.

    Put missed detections, unsafe tool requests, reviewer overrides, false positives, escaped defects, user-reported incidents, and excessive consumption into the same operating backlog as product defects. Each item needs an owner, a release criterion, and a test that demonstrates the correction. This keeps governance attached to the product lifecycle instead of turning it into a parallel paperwork process.

    Express repeatable rules as policy that can be versioned, reviewed, tested, and enforced in delivery and runtime systems. A shared policy-as-code foundation across product, security, and IT reduces control drift and makes audit evidence more predictable. Examples include permitted models by data class, allowed connector scopes, required approvals by action class, egress destinations, environment-specific usage caps, and mandatory audit fields.

    Use 90 days to prove one controlled path to production

    A broad governance program can spend months debating universal policy while risky workflows continue to appear. A better starting point is a 90-day path that inventories usage, pilots within guardrails, and productionizes only the workflow that earns it.

    Days 0-30: Establish the boundary

    • Inventory active and proposed AI workflows, including employee-created tools and unapproved connectors.
    • Classify the data, systems, identities, and actions involved.
    • Select one or two consequential business workflows rather than spreading controls across every experiment.
    • Name the product owner, security owner, data owner, business approver, and incident owner.
    • Draw the complete action path and identify crown jewels, trust boundaries, and irreversible outcomes.
    • Put basic access, audit, retention, tool, egress, approval, shutdown, and rollback controls in place.
    • Define the intended-behavior set, adversarial scenarios, acceptance limits, and prohibited outcomes before the pilot begins.

    The exit condition is not an approved policy document. It is a workflow whose owner, data, identity, tools, action boundary, failure modes, and emergency controls can all be named.

    Days 31-60: Prove the controls in a pilot

    • Run the workflow in a sandbox with the lowest autonomy level that still tests the business value.
    • Build the evaluation harness around a maintained reference set and a separate adversarial set.
    • Test prompt injection, data leakage, invalid outputs, connector abuse, privilege boundaries, and dependency failure.
    • Instrument identity, retrieval, model, authorization, tool, approval, cost, and action events.
    • Train the human approver on the decision interface and record corrections, overrides, and unclear evidence.
    • Rehearse containment by suspending the workflow, revoking its credentials, preserving evidence, and rolling back a test action.
    • Review quality, security, user outcome, latency, and cost together. A workflow does not pass because only one dimension looks good.

    Use AI to augment a person before allowing it to execute independently. The pilot should prove both the useful task and the control loop. If the team cannot detect a forbidden request or reconstruct an action, higher autonomy is premature even when the model’s normal-case output looks strong.

    Days 61-90: Productionize with a narrow permission envelope

    • Release only the workflow that met its predefined product, security, operational, and economic criteria.
    • Start with the permissions and autonomy already proven in the pilot; do not widen them merely because the environment changed to production.
    • Enable dashboards, alerts, usage caps, environment tagging, escalation routes, and the tested shutdown control.
    • Train frontline users to recognize unreliable output, suspicious requests, impersonation attempts, and the correct escalation path.
    • Retire duplicate or low-yield experiments that add vendors, connectors, identities, or spend without producing enough value.
    • Treat every request for broader data, another tool, or greater autonomy as a new control decision with updated tests.

    At the end of the 90 days, do not ask only whether the workflow shipped. Ask whether you can identify who initiated every consequential action, prove which data and permissions were used, see when a control blocked abuse, stop the workflow quickly, recover from an error, and quantify quality, response, latency, and cost. Any missing answer identifies the next control to build.

    Key takeaways

    • Govern the complete AI workflow, including retrieval, identities, connectors, actions, logs, and feedback loops.
    • Begin with crown jewels and concrete business consequences, then map every trust boundary that can affect them.
    • Match autonomy to blast radius and reversibility. A model approval does not authorize every use of that model.
    • Place meaningful human approval at the consequential action boundary and show the reviewer exactly what will happen.
    • Combine AI telemetry with identity, endpoint, application, and network signals so misuse can be detected and contained.
    • Increase autonomy only after legitimate and adversarial evaluations, auditability, shutdown, and rollback have been demonstrated.

    Your next governance meeting should end with one selected workflow, one accountable owner, one drawn action path, and one explicit list of prohibited outcomes. If the team cannot show how that workflow will be stopped and investigated, keep it in recommendation mode and build the missing control before expanding its authority.

    References

  • How to Prove AI Agent ROI Without Sacrificing Privacy

    How to Prove AI Agent ROI Without Sacrificing Privacy

    Your AI agent is live. Usage is rising. Now the executive question has shifted from “Can it work?” to “Is it worth funding?” A dashboard full of conversations, messages, and active users will not answer that question. Worse, collecting every prompt and response can turn the measurement system into a privacy liability.

    You need an evidence chain that connects agent behavior to a business outcome, subtracts the full cost of producing that outcome, and respects clear limits on what data may be collected. That lets you decide whether to expand the agent, improve a weak workflow, or stop investing before a promising experiment becomes an expensive habit.

    Start with the decision, not the dashboard

    Agent analytics should reduce uncertainty about a product decision. If a metric cannot change a decision, it probably does not deserve a place in the executive view.

    Begin by writing the decision in plain language: “Should I expand the onboarding agent to more accounts?” “Should support automate this issue type?” “Should the website agent keep booking meetings?” Then identify the business outcome that would justify the decision. The useful measurement layer connects agent interactions to adoption, successful deflection, time-to-value, activation, and retention, rather than treating engagement as the final result.

    I would not approve an ROI claim built on conversation volume, message count, or session depth alone. Those metrics describe activity. A long session could indicate deep engagement, repeated misunderstanding, or an inability to exit. You need an outcome event before you can interpret the activity around it.

    Decision questionPrimary outcomeDiagnostic metricsGuardrails
    Should the onboarding agent expand?Activation or onboarding completionAdoption, task success, time-to-valueFailure and human-handoff rates
    Should support automate this issue type?Successfully resolved eligible issuesDeflection, time-to-resolution, escalationRepeat attempts and unresolved cases
    Should the website agent receive more traffic?Incremental qualified demand or conversionQualified conversations, booked meetings, journey progressionSession quality and inappropriate handoffs
    Can the workflow operate safely?Successful tasks within approved policyLow-confidence responses, repeated handoffs, anomalous usageAccess, retention, consent, and audit compliance

    Every rate also needs an eligible denominator. “Twenty percent of customers use the agent” is unhelpful if only a fraction encountered the task it was designed to handle. Define adoption as agent users divided by eligible users or accounts. Define task success as completed eligible tasks divided by eligible attempts. Define deflection as eligible issues resolved without human support divided by eligible issues handled by the agent.

    Do not assume that the absence of a handoff means successful deflection. The user may have abandoned the interaction. Require a positive resolution signal, a completed action, or another outcome that represents the job being done. If none exists, label the interaction “no handoff observed,” not “resolved.” That wording prevents a telemetry gap from becoming a financial claim.

    Build the ROI model backward from realized value

    The basic calculation is familiar: ROI = (realized benefit – total cost) / total cost. The difficult work is deciding what qualifies as realized benefit and keeping the numerator free of double counting.

    1. Choose the unit of value. Use the unit the agent actually changes: a resolved issue, an activated account, a qualified opportunity, or a completed workflow.
    2. Define the counterfactual. Record what would have happened without the agent. A historical baseline can orient the team, but a valid control is stronger evidence.
    3. Translate incremental outcomes into value. Use a finance-approved value for the economic outcome, not a convenient value for an intermediate click or conversation.
    4. Subtract the full operating cost. Include implementation, integrations, model or platform usage, analytics, human review, escalations, maintenance, and governance.
    5. Keep quality and risk visible. An agent that lowers cost by shifting work to customers or producing unsafe answers has not created durable value.

    For support, start with successfully deflected eligible cases and the validated cost of handling those cases through the previous path. Be precise about what changes economically. If headcount, vendor spend, overtime, or service capacity does not change, do not report theoretical labor as cash savings. Call it capacity reclaimed and state what the organization did with that capacity. The distinction matters when the business case reaches finance.

    For a website or sales agent, a qualified conversation or booked meeting is usually an intermediate result. An agent may qualify interest, book meetings, and connect visitors to relevant product experiences, but those actions become revenue evidence only when you follow the assigned cohort into a downstream outcome. Until then, report funnel progression rather than attributing revenue.

    For an in-product agent, activation and retention can be economically meaningful, but correlation is not incrementality. Customers who choose to use an agent may already be more motivated. Use engagement as a diagnostic signal, then test whether exposure changes activation, onboarding completion, or retention relative to an appropriate control.

    Avoid adding several representations of the same benefit. If activation leads to retention, and retention leads to recurring revenue, adding all three values inflates the result. Choose the terminal economic outcome you can support. Use the earlier events to explain how the agent produced it.

    Risk deserves its own ledger. Low-confidence responses, repeated handoffs, policy violations, and anomalous usage are leading indicators that can change a rollout decision. Do not force them into a monetary estimate unless the organization has a credible loss model. A transparent risk indicator is more useful than a precise-looking number built on unsupported assumptions.

    Measure outcomes without building a transcript warehouse

    You do not need every prompt and response to understand whether an agent works. In most product decisions, a small sequence of structured events is more useful than a large collection of unstructured conversation data.

    Instrument the workflow from eligibility to outcome:

    • agent_eligible: the user or account encountered an approved use case.
    • agent_invoked: the agent was opened or called.
    • agent_action_attempted: the agent tried to complete the defined job.
    • agent_task_completed: the product confirmed the success condition.
    • agent_handoff: the interaction moved to a human or another approved path.
    • business_outcome_observed: activation, resolution, qualification, or another downstream result occurred.

    Each event should carry only the dimensions needed for an approved decision: use-case identifier, agent or workflow version, placement, experiment assignment, structured outcome status, and an enumerated failure or handoff reason. Use an account, user, or cohort identifier only when it has been approved for that purpose. If a field does not change a product, operational, or risk decision, remove it.

    A privacy-first event contract should keep payloads sparse and free of secrets, tokens, raw free-form text, and personally identifiable information. An allowlist is easier to govern than collecting everything and attempting to clean it later. It also improves analytical consistency because teams compare known categories instead of interpreting an uncontrolled stream of text.

    If qualitative conversation review is necessary, treat it as a separate, explicitly governed workflow. Do not quietly copy raw conversations into the default analytics stream. Define who may access them, why access is necessary, how consent and retention requirements apply, and when the data is removed. Security, privacy, and legal owners should evaluate that workflow against the organization’s actual obligations.

    Review every proposed field with five questions:

    1. Which decision will this field change?
    2. Could it contain personal, confidential, or secret information?
    3. Who needs access, and can role-based controls enforce that boundary?
    4. How long is it needed for the stated purpose?
    5. Can the team audit its use and remove it when the purpose ends?

    Data minimization is not an obstacle to ROI measurement. It forces the team to define success before collecting data. That usually produces a cleaner event taxonomy, a more defensible dashboard, and fewer arguments about what a conversation appeared to mean.

    Separate useful correlation from defensible proof

    Agent analytics can reveal where users adopt the experience, where they fail, and which segments behave differently. That is enough to generate product hypotheses. It is not always enough to claim that the agent caused a business outcome.

    Run an experiment when the result will influence funding, rollout, staffing, or a material revenue claim:

    1. Write one hypothesis. Name the eligible population, the agent exposure, the expected business outcome, and the decision that follows.
    2. Select one primary outcome. Activation, successful resolution, or downstream conversion is stronger than a composite score that can move for several unrelated reasons.
    3. Set the minimum detectable effect before looking at results. This is the smallest change worth detecting and acting on. It prevents the team from treating any favorable movement as meaningful.
    4. Assign a control where it is safe and practical. Randomized exposure is the clearest way to reduce self-selection. When randomization is unsuitable, use a phased rollout or a carefully matched comparison and label the evidence as weaker.
    5. Freeze the measurement definition during the test. Verify exposure, success, failure, and handoff events before interpreting the result.
    6. Monitor guardrails with the primary outcome. A conversion gain accompanied by more unresolved tasks, escalations, or risky responses is not a clean win.
    7. Apply a pre-agreed decision rule. Expand, revise, or stop based on the evidence threshold established before the test.

    Segment analysis belongs after the overall measurement design is credible. Compare eligible cohorts by use case, journey stage, placement, or another approved dimension. Do not keep slicing until a favorable result appears. Use segment differences to form the next hypothesis, especially when the groups are small or were not specified in advance.

    Keep correlation visible even when it cannot support an ROI claim. A repeated handoff pattern can expose a missing capability. A drop between invocation and action attempt can reveal confusing conversation design. A weak completion rate for one placement can guide the next test. The label matters: “observed association” supports discovery; “incremental effect” supports attribution.

    Turn the business case into a 90-day operating loop

    A one-time ROI spreadsheet decays as soon as the agent, workflow, model, traffic mix, or cost structure changes. Treat measurement as an operating discipline with named owners and a regular decision cadence.

    In the first phase, choose one high-intent workflow and establish its baseline. Write the eligible population, success condition, economic outcome, failure states, and approved event fields. Product should own the outcome hypothesis. Engineering should own telemetry reliability and versioning. Security and privacy owners should approve collection and access. Customer-facing teams should help define whether a handoff or resolution is genuinely useful. Finance should validate the economic assumptions.

    In the second phase, instrument the journey end to end and test the instrumentation itself. Confirm that eligibility, exposure, action, completion, failure, handoff, and downstream outcomes reconcile. Version the agent and workflow so a prompt, tool, or placement change does not silently mix different product experiences in one time series.

    In the final phase, run two or three focused experiments and review the evidence weekly. Changes to copy, timing, placement, onboarding help, or product guidance are useful candidates when they address a known break in the journey. The review should end with a recorded decision, an owner, and the evidence still missing.

    By day 90, produce a decision record that shows the baseline, incremental outcome where it was tested, realized benefit, full cost, quality guardrails, privacy controls, and the next investment decision. If the team cannot connect the interaction to an outcome by then, the correct conclusion is not that the agent has no value. It is that the current measurement system cannot support an ROI claim.

    Key takeaways

    • Start with the funding or rollout decision, then select the business outcome that would justify it.
    • Use eligible users, accounts, issues, or tasks as denominators; raw conversation volume is not adoption or value.
    • Count realized economic benefit, subtract the full operating cost, and avoid valuing the same outcome twice.
    • Prefer structured outcome events over raw prompts and transcripts; collect only fields tied to an approved decision.
    • Use controls and a predeclared minimum detectable effect before describing a correlation as incremental ROI.
    • Review outcome, cost, quality, and privacy signals together so optimization does not hide transferred work or increased risk.

    Your next move is to take one production agent workflow and write down four things: its eligible denominator, its confirmed success event, its terminal economic outcome, and its approved event fields. If those cannot fit into a clear measurement contract, do not add another dashboard yet. Fix the contract first, then let the evidence determine whether the agent earns its next stage of investment.

    References

  • AI-Personalized Activation: A Practical Path to Retention

    AI-Personalized Activation: A Practical Path to Retention

    Your onboarding experiment is lifting completion, and the AI recommendations are getting clicks. Yet the retention curve is barely moving. That is the warning sign: the product has become better at prompting activity, but not necessarily better at creating lasting value.

    AI-personalized activation works when it selects the right path to value for each user, then helps that user repeat the valuable behavior. Treating the first five minutes and the later retention journey as one system gives you a practical way to build it.

    Start with recurring value, then work backward to activation

    Activation is not account creation, onboarding completion, or the first AI-generated output. Those events may be easy to count, but they do not prove that the user solved a meaningful problem. A stronger activation event is an observable early behavior that predicts the user will return for the product’s recurring value.

    This distinction matters because retention is evidence of repeated value. If you optimize an earlier event without connecting it to that value, AI can make the funnel look healthier while the underlying product relationship stays unchanged.

    Define the value chain for each important segment before choosing a model or personalization surface:

    1. Recurring job: What does this user repeatedly rely on the product to accomplish?
    2. Value event: What observable event shows that the job was completed successfully?
    3. Activation evidence: What earlier behavior is associated with users reaching that value event again?
    4. Personalization decision: Which choice could the product make differently to help this user reach the event sooner?
    5. Failure condition: What would show that the experience created activity without durable value?

    Consider a collaborative content product. Generating a draft may demonstrate the AI, but it is weak evidence of value if the user abandons the draft. Editing, approving, or publishing the output may be a better activation candidate. For a workflow product, importing data may only be setup; completing the first real workflow and returning to manage the next one may carry more meaning.

    Do not assume the same activation event applies to every segment. A solo operator, a team administrator, and an invited contributor can have different jobs, permissions, and paths to value. Use cohort analysis to test whether each proposed event actually separates users who later return from those who do not. Correlation identifies a candidate; an experiment is still needed to determine whether causing more users to complete it improves retention.

    A useful personalization thesis fits into one sentence: For this segment and job, use these permitted signals to select this next action, so the user reaches this value event sooner and repeats this workflow more often. If the team cannot complete that sentence precisely, the scope is not ready for AI.

    Build the decision system before choosing the model

    A personalization system is not just a prediction. It is a chain of signals, a decision, a product action, and feedback. Most avoidable failures occur at the connections between those parts: the signal is stale, the action is too aggressive, the feedback measures a click instead of value, or no safe fallback exists.

    Create a personalization contract for every use case. Record:

    • Audience: the eligible segment and the reason it needs a different path.
    • Signals: the declared intent, current context, observed behavior, or account information used in the decision.
    • Decision: the exact choice the system is allowed to make.
    • Action: what changes in the interface, recommendation, draft, or workflow.
    • Success: the activation and retention outcomes expected to move.
    • Guardrails: the behaviors or outcomes that must not deteriorate.
    • Fallback: what the user sees when signals are missing, contradictory, stale, or unavailable.
    • Control: how the user can understand, correct, snooze, or disable the personalization.

    For new users, declared intent is usually more useful than pretending the product already knows them. Ask a small setup question when the answer will materially change the path. Use current-session context next, followed by observed behavior as it accumulates. Predictions should supplement those signals, not overwrite explicit choices.

    Treat the cold start as a designed product state. When confidence is high, offer the tailored path. When evidence is sparse, use a segment-level default. When signals conflict, ask the user instead of resolving the ambiguity invisibly. If personalization is unavailable, preserve a coherent universal path. Graceful degradation keeps an inference problem from becoming a broken onboarding experience.

    Start on a high-intent surface where the user is already trying to make progress. Good early candidates include a recommended next step, an empty-state prompt, a preconfigured starting point, a contextual tooltip, or a shorter route through setup. These interventions can reduce time-to-value without redesigning the entire product around an immature prediction.

    Governance belongs inside the contract. Document why each signal is necessary, where it came from, how long it persists, who can access it, and how the user can control its use. Data minimization reduces both privacy exposure and the number of dependencies the team must maintain. Do not collect a sensitive attribute merely because it might improve prediction, and inspect apparently harmless inputs for proxies that could disadvantage smaller segments.

    I use a simple product test: if the experience cannot be explained in a sentence, tested against a holdout, and declined without friction, it has not earned a wider rollout.

    Design the journey from first success to repeated success

    If personalization stops when onboarding ends, it may shorten setup without strengthening retention. The experience should change after the user reaches first value. At that point, the job is no longer to explain the product. It is to help the user repeat the successful workflow, recover when progress stalls, and discover the next relevant layer of value.

    Map personalization to the user’s current value state:

    • Not yet activated: remove the next obstacle and direct attention to the shortest credible path to first value.
    • Activated but shallow: help the user repeat the successful workflow before introducing unrelated capabilities.
    • Regular but narrow: recommend an adjacent workflow only when it supports the same job or a clear next milestone.
    • Stalled: identify the incomplete step, summarize what has already happened, and offer a direct recovery action.
    • Established: reduce recurring effort through summaries, drafts, recommendations, or carefully controlled automation.

    Each intervention needs an exit condition. A setup prompt should disappear after setup. A recommendation should stop after rejection or completion. A recovery nudge should not follow the user indefinitely. Without exit conditions, personalization becomes stale UI that repeatedly reveals how little the system understands.

    Feedback also needs a defined destination. A thumbs-down control is decorative unless it changes a future decision, suppresses an unsuitable recommendation, or routes a quality problem for review. Capture corrections and dismissals alongside positive engagement. Otherwise, the model learns only from users willing to follow its suggestions.

    Separate assistance from autonomy as the experience matures:

    1. Recommend: suggest the next action and let the user perform it.
    2. Prepare: create a draft, configuration, or plan for the user to inspect and approve.
    3. Act: execute a multi-step workflow within explicit boundaries, with approval gates for consequential actions and an audit trail of what happened.

    The progression matters. A system that recommends the wrong action creates friction. A system that takes the wrong action can alter customer data, create confusing downstream work, or weaken trust. Higher autonomy should require stronger evidence, clearer permissions, reliable undo paths, and better operational monitoring.

    Run experiments that connect activation to cohort retention

    Click-through rate can tell you whether a recommendation attracted attention. It cannot tell you whether the recommendation accelerated value, displaced a better path, or improved retention. Build the experiment around the causal chain you actually care about.

    Write an experiment card before implementation:

    • Hypothesis: which decision will change for which eligible users, and why that should affect the activation event.
    • Randomization unit: user or account. Use the account when collaborators share the experience and treatment could spill across users.
    • Primary outcome: the segment-specific activation event, not a generic interaction with the AI.
    • Downstream outcome: return to the recurring value event during the product’s natural usage interval.
    • Diagnostic measures: exposure, acceptance, completion, time-to-value, corrections, dismissals, and fallback use.
    • Guardrails: errors, undo activity, support demand, opt-outs, abandonment, latency, and adverse effects by important segment.
    • Decision rule: what evidence will justify rollout, iteration, restriction, or rejection.

    Set the minimum detectable effect from traffic and variance before reading the result. A target effect that the available sample cannot detect will produce an inconclusive experiment, no matter how polished the dashboard looks. Keep a persistent holdout when you need to distinguish durable lift from novelty or broad changes elsewhere in the product.

    Measure assignment, eligibility, exposure, and outcome separately. If only highly engaged users qualify for a recommendation, the exposed cohort will naturally look healthier. Report the effect for assigned eligible users, then use exposure analysis to diagnose the mechanism. Do not present the exposed-versus-unexposed comparison as causal proof.

    Inspect the full time-to-value distribution, not only the average. A personalized path can help users with rich signals while making sparse-signal users slower. Segment results by the dimensions defined in the hypothesis, and examine smaller groups for harm even when they are not large enough to prove a separate lift.

    Use these rollout decisions consistently:

    • Activation and retention improve, with guardrails intact: expand carefully and continue monitoring by cohort.
    • Activation improves but retention is unresolved: keep the rollout constrained until the downstream observation window is complete.
    • Activation improves but retention declines: reject the experience or change the activation target. The system is accelerating the wrong behavior.
    • The average is flat but a pre-specified segment benefits: consider a segment-only experience if the result is adequately powered and other segments are protected.
    • A trust or operational guardrail deteriorates: pause expansion even when the primary metric rises.

    This discipline prevents a common strategic mistake: declaring success at the top of the funnel and asking retention to catch up later. The burden of proof belongs to the complete value path.

    Earn the right to deepen personalization

    Scale capability in evidence-gated stages. Begin with rules in one high-traffic, high-intent journey. Add contextual recommendations only after instrumentation and fallbacks are reliable. Introduce agentic actions only after the product can explain decisions, enforce permissions, request approval, record actions, and recover safely.

    A practical maturity path looks like this:

    • Crawl: rules-based routing, explicit inputs, a universal fallback, a visible opt-out, and one well-defined activation outcome.
    • Walk: contextual recommendations using behavioral signals, stronger feedback loops, segment-level evaluation, and continuous controlled experiments.
    • Run: multi-step agentic workflows with scoped permissions, approval gates, audit trails, undo paths, and operational monitoring.

    Before moving to the next stage, pass four gates. The value gate asks whether the current experience improves a meaningful user outcome. The evidence gate asks whether the effect survives a controlled experiment and appears in downstream cohorts. The trust gate asks whether users can understand and control the behavior. The operations gate asks whether the product can detect failures and recover without leaving the user to reconstruct what the AI did.

    Review the system weekly as a product portfolio, not a collection of permanent features. Track signal coverage, fallback frequency, model or rule failures, corrections, opt-outs, activation, repeated value, and segment-level retention. Remove interventions that add complexity without durable lift. A personalization layer becomes expensive when obsolete decisions continue to run simply because nobody owns their retirement.

    Key takeaways

    • Define activation as an early behavior linked to recurring value, not merely completion or AI engagement.
    • Give every personalization use case an explicit audience, signal set, decision, outcome, fallback, and user control.
    • Change the experience after first success so personalization supports repetition, recovery, and the next relevant milestone.
    • Judge experiments on downstream retention cohorts and guardrails, not recommendation clicks alone.
    • Increase autonomy only after value, evidence, trust, and operational readiness have all improved.

    Your next move is not to choose a more capable model. Pick one high-intent journey, write its personalization contract, and trace the proposed activation event to repeated value. If that chain is measurable and the fallback is safe, ship the smallest controlled version. Let cohort evidence determine how much personalization the product earns next.

    References

  • Inside Japan’s AI Marketing Shift: How 500 Teams Boost Efficiency, Results, and Careers

    Inside Japan’s AI Marketing Shift: How 500 Teams Boost Efficiency, Results, and Careers

    I just finished reviewing new findings on Japan’s marketing landscape, and the signal is clear: AI isn’t just a shiny tool—it’s a force multiplier for outcomes and careers. The headline that caught my attention, "Amplitude Releases New Research in Japan: Marketers are Unlocking Efficiency, Results, and Career Growth," aligns with what I’m seeing on the ground: teams that blend disciplined analytics with pragmatic AI adoption are pulling ahead.

    Amplitude released a new survey of 500 Japanese marketers, which reveals how teams are benefiting from AI. Get the insights from the data

    Here’s how I interpret the shift. AI accelerates the cycle from insight to action when it’s grounded in a unified analytics platform. With Amplitude analytics stitched into campaign and product signals, marketers can move beyond vanity metrics to diagnose true drivers of activation, engagement, and retention. That’s where efficiency compounds: fewer blind spots, faster iteration, and clearer attribution of what actually drives results.

    On the strategy side, I’m seeing two dominant patterns. First, gen ai is speeding up creative workflows—audience research, message testing, and content generation—without sacrificing brand rigor. Second, agentic AI is emerging in operational loops: routing leads, prioritizing segments, and suggesting next-best actions based on behavioral data. The common denominator is data governance; without clean event schemas and consent-aware pipelines, AI amplifies noise instead of signal.

    For product-led growth motions, this research validates what empowered product teams have practiced for years: instrument the customer journey, frame outcomes vs output OKRs, and experiment in short, learnable cycles. When marketing, product, and data join forces as true product trios, teams can run in-app guides and product tours, tune onboarding, and perform rigorous retention analysis that ties growth to product value rather than spend.

    My playbook in this environment is simple but disciplined. Start with first principles decision making: define the problem, the decision, and the evidence required. Use a unified analytics platform to connect lifecycle events across acquisition, activation, and expansion. Align go-to-market strategy with product roadmapping and sprint planning, so insights move directly into experiments—not slide decks. Then close the loop with clear outcome metrics and QBRs that reward learning velocity, not activity volume.

    There’s also a career arc embedded in this shift. Marketers who cultivate analytical fluency and AI literacy are becoming indispensable partners to product management leadership. They can articulate a differentiated value proposition, shape product positioning with live behavioral data, and influence board-level narratives with credible, causal evidence. That combination—story plus signal—unlocks both performance and professional growth.

    My commitment going forward is to operationalize these lessons: tighter event taxonomy, sharper outcomes framing, and more systematic experimentation across channels and in-product touchpoints. With the right data foundation and a pragmatic AI strategy, we can convert curiosity into capability—and capability into repeatable growth.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • How Luminance Builds Legal-Grade™ AI at Scale: My Product Lens on Trust and GTM

    How Luminance Builds Legal-Grade™ AI at Scale: My Product Lens on Trust and GTM

    I’m fascinated by how the most credible legal-tech platforms operationalize AI in the enterprise, where risk tolerance is near zero and trust is the product. When I evaluate solutions in this space, I look for rigor in model design, governance, and go-to-market execution—not just raw model performance.

    Discover how Luminance CEO Eleanor Lightbody builds Legal-Grade™ AI for enterprise. See how their specialized, agentic AI models lawyers trust at scale.

    That framing resonates with me. “Legal-Grade™” isn’t a slogan; it’s a product requirement that implies auditable decisions, explainable outputs, robust data governance, and demonstrable accuracy under real-world legal workflows. “Agentic AI” adds another layer: autonomous orchestration of tasks with explicit guardrails, role definitions, and escalation paths to humans-in-the-loop.

    From a product management perspective, I start with outcomes. For legal teams, the jobs-to-be-done are concrete: contract analysis and redlining, due diligence, compliance reviews, investigations, and eDiscovery. The success criteria are equally concrete: precision and recall on domain-specific clauses, latency under load, traceability of sources, and the ability to scale across matter types, jurisdictions, and languages without degrading trust.

    Building that foundation requires deliberate AI strategy. I look for domain-specialized models, retrieval-augmented generation tuned to legal corpora, evaluation harnesses with gold-standard datasets, and continuous red-teaming. Just as important are deployment choices—on-prem or VPC isolation, encryption in transit and at rest, strict PII handling, and granular access controls—to satisfy the security posture of enterprise legal and compliance teams.

    Governance is where “legal-grade” is won or lost. Robust audit trails, versioned prompts and policies, model cards, clear data lineage, and event logs that support defensibility are table stakes. Human review workflows, explainability tooling, and remediation paths ensure the system remains trustworthy when edge cases arise.

    On product process, I favor empowered product teams and forward-deployed engineers partnering directly with attorneys and legal ops. Co-designing workflows with subject-matter experts surfaces the right constraints early: how redlines are presented, what confidence thresholds trigger review, and where to anchor the user experience in familiar legal tools and document structures.

    Competitive differentiation and product positioning hinge on clarity: what specific legal outcomes are delivered faster, safer, or more accurately than alternatives? I prioritize transparent benchmarking against baselines, proof-of-value pilots that mirror production data conditions, and pricing that aligns to measurable outcomes (e.g., time-to-first-draft, review throughput, or risk reduction) rather than abstract usage metrics.

    Go-to-market strategy in enterprise legal is a discipline in itself. Expect rigorous InfoSec reviews, stakeholder alignment across legal, IT, and procurement, and the need for customer references that demonstrate “trust at scale.” Clear messaging around value proposition, safety posture, and operational readiness shortens cycles and builds confidence among risk-averse buyers.

    The big takeaway for product leaders: Legal-Grade™ AI isn’t about novel models; it’s about orchestrating specialization, safeguards, and enterprise-grade delivery into a coherent system that lawyers can rely on daily. When agentic AI is harnessed with the right guardrails and domain depth, it becomes a force multiplier for legal teams—accelerating work without compromising standards.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image