{ "schema_version": "1.0", "generatedAt": "deterministic-static-build", "source": "data/executivePageContent.js", "cards": [ { "id": "executive-ai-strategy", "canonical_url": "https://teamstation.dev/ai-strategy", "title": "AI strategy starts with a business decision", "description": "Prioritize enterprise AI investments by business value, readiness, ownership, and risk before committing budget or building a nearshore team.", "direct_answer": "AI strategy decides which business problems deserve investment, where AI is a reasonable option, and what evidence would justify continuing. Start with the outcome, not a model purchase or a hiring target.", "decisions": [ [ "Business value", "Name a customer or operating outcome and its current baseline.", "Business sponsor" ], [ "Readiness", "Confirm data access, integration ownership, and a usable evaluation method.", "Technology and data leads" ], [ "Investment boundary", "Set a budget ceiling, review date, and conditions for stopping.", "Finance and portfolio owner" ] ], "steps": [ "List the decisions or workflows that need to improve, including options that do not require AI.", "Rank opportunities against the same value, risk, and readiness criteria. Record the assumptions behind the ranking.", "Fund one bounded evaluation with a named business owner and an agreed success measure.", "Continue, change, or stop using measured results and full operating cost, not demo quality." ], "evidence": { "id": "strategy-investment-record", "title": "Investment decision record", "reference": "MAP 1.4", "premise": "NIST calls for a defined business value or use context.", "columns": [ "Record", "Evidence to collect", "Decision it supports" ], "rows": [ [ "Outcome baseline", "Current task completion time, quality, or revenue measure, with its source and period.", "Whether the problem is material." ], [ "Alternative", "A comparison with process changes, existing software, and an AI option.", "Whether AI is needed." ], [ "Continuation rule", "An agreed acceptance threshold and accountable budget owner.", "Whether another investment is justified." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), MAP 1.4", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "This record is a planning method, not a forecast of returns. A plausible use case does not establish technical feasibility or customer demand.", "faqs": [ { "question": "What should an AI strategy produce?", "answer": "A prioritized set of business problems, accountable owners, budget limits, evaluation criteria, and explicit decisions to continue, change, or stop." }, { "question": "Should we hire an AI team before choosing a use case?", "answer": "Define the work and its constraints first. Then assess existing capabilities and choose the role mix needed to deliver and operate it." } ], "workflow": { "title": "From business problem to funding decision", "nodes": [ [ "Define the outcome", "Agree what should improve and measure the current process." ], [ "Compare the options", "Test process repair, existing software and AI against the same need." ], [ "Fund the next step", "Commit only to the next evidence-producing stage." ] ] }, "scenario": { "title": "Should you automate customer onboarding?", "situation": "An enterprise wants faster onboarding. Sales blames slow document review, operations points to missing customer information, and IT has been asked to buy an AI tool. Those are different problems, so don't approve one solution before checking where the delay occurs.", "options": [ [ "Repair the intake", "Use required fields and clearer ownership when missing information causes the wait." ], [ "Assist the reviewer", "Test document extraction when reading is the constraint and a reviewer can verify the output." ], [ "Defer the investment", "Pause when source access, a business owner or an acceptance measure is missing." ] ], "decision": "Compare completion time, correction work and customer outcomes using the same workflow boundary. Count integration, review, infrastructure and ongoing support in the budget. A faster extraction step doesn't establish a faster onboarding process." }, "engagement": { "fit": "Bring a business problem, an accountable sponsor and access to the people doing the work. We can scope the engineering delivery around that decision; a list of AI tools isn't enough to size a team.", "deliverables": [ "A prioritized workflow and named acceptance owner.", "A delivery backlog with data, integration and review dependencies.", "A role-based capacity scenario with assumptions and exclusions." ], "boundary": "Keep strategy approval with your business and finance owners. Scope, fees and acceptance criteria belong in the engagement agreement; this guide doesn't promise a return." }, "connections": [ { "text": "Once the investment has an owner, separate workflow rollout from the original funding decision.", "link": [ "/ai-transformation", "Plan the AI transformation sequence" ] }, { "text": "Before adding seats, identify the skills and platform capabilities that the selected workflow actually needs.", "link": [ "/ai-capability-planning", "Map AI capability gaps" ] } ], "next_step": [ "/ai-transformation", "Turn the investment decision into a delivery sequence" ], "related_links": [ [ "/ai-operating-model", "Assign ownership before funding more pilots" ], [ "/ai-capability-planning", "Check capabilities behind the investment" ], [ "/ai-workforce-planning", "Separate team needs from tool choices" ], [ "/ai-governance", "Set the risk boundary" ], [ "/ai-capacity-planning", "Model the delivery budget" ], [ "/research", "Review TeamStation research and methods" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-strategy.md", "markdown_sha256": "061323a78abcd93c05014a05a55b755e30665d7efca7d948b46959db499b211b", "sha256": "be9d3756b70e69266b2e5d0245aa2aad2349d88721006387a3ca2295281f1492" }, { "id": "executive-ai-transformation", "canonical_url": "https://teamstation.dev/ai-transformation", "title": "AI transformation changes how work gets done", "description": "Plan enterprise AI rollout, adoption and support with workflow owners, practical checkpoints and evidence before expanding delivery.", "direct_answer": "AI transformation is a change program that moves a business workflow from its current process to an evaluated, supported way of working. Technology delivery, user adoption, and operating ownership must progress together.", "decisions": [ [ "Sequence", "Choose one workflow whose dependencies and owner are known.", "Transformation lead" ], [ "Adoption", "Agree how users will learn, challenge, and fall back from the new process.", "Business process owner" ], [ "Scale", "Require evidence from real use before extending the rollout.", "Executive sponsor" ] ], "steps": [ "Map the existing workflow and record its baseline, including manual exceptions.", "Prepare data access, support ownership, training, and evaluation before the pilot starts.", "Run a bounded rollout with an accessible fallback and a way for users to report failures.", "Review adoption, rework, service quality, and operating cost together before widening scope." ], "evidence": { "id": "transformation-adoption-review", "title": "Adoption and change review", "reference": "GOVERN 5.2", "premise": "NIST connects feedback from relevant actors to system changes.", "columns": [ "Checkpoint", "Evidence to collect", "Who decides" ], "rows": [ [ "Pilot exit", "User feedback and unresolved exceptions alongside technical results.", "Process owner and delivery lead" ], [ "Operating handover", "Support instructions, escalation contacts, and a demonstrated fallback.", "Service owner" ], [ "Expansion", "Comparable baseline and post-change observations, including rework.", "Sponsor and finance owner" ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), GOVERN 5.2", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "A pilot result is specific to its users, workload, and controls. Do not assume it transfers unchanged to another business unit.", "faqs": [ { "question": "How is AI transformation different from an AI pilot?", "answer": "A pilot tests an idea. Transformation also changes responsibilities, user workflows, support, controls, and investment decisions so the capability can operate beyond the trial." }, { "question": "What should we measure during rollout?", "answer": "Measure the intended business outcome alongside adoption, rework, exceptions, service quality, and full operating cost. Keep the baseline and observation period visible." } ], "workflow": { "title": "Change the workflow, then widen the rollout", "nodes": [ [ "Observe current work", "Include exceptions, handoffs and the people who absorb rework." ], [ "Run a bounded change", "Give users training, feedback and a workable fallback." ], [ "Decide on expansion", "Review adoption and business outcomes with operating cost." ] ] }, "scenario": { "title": "A support assistant works in a demo, but not on shift", "situation": "A support team can generate draft replies, but agents still search several systems to verify each answer. The prototype produces text; the daily job includes checking access, resolving exceptions and recording the outcome. The rollout needs to cover that whole job.", "options": [ [ "Keep it assistive", "Use drafts with a named reviewer while verifying source quality and exception handling." ], [ "Redesign the workflow", "Connect permitted sources and make corrections visible where support staff already work." ], [ "Stop the rollout", "Return to the supported process if errors, verification effort or customer harm exceed the agreed limit." ] ], "decision": "Record why people bypass the new process instead of treating login counts as success. Compare similar cases before and after the change, and keep difficult cases in the evaluation. Don't expand simply because the demonstration was well received." }, "engagement": { "fit": "A useful delivery brief names the workflow, its users and the operating owner. We can help scope implementation and engineering coverage alongside your internal change and support teams.", "deliverables": [ "A sequenced rollout backlog with dependencies and acceptance checkpoints.", "Integration, evaluation and operating handover work assigned to roles.", "A support and review capacity plan for the rollout period." ], "boundary": "User adoption and business change need your process owners. Engineering delivery alone doesn't establish that a new workflow is accepted or effective." }, "connections": [ { "text": "If teams disagree about who supports the new workflow, resolve the operating model before expanding access.", "link": [ "/ai-operating-model", "Define product and platform ownership" ] }, { "text": "A rollout checkpoint needs release evidence, not just a project status update.", "link": [ "/ai-delivery-governance", "Set the release and recovery checks" ] } ], "next_step": [ "/ai-operating-model", "Define who owns the ongoing service" ], "related_links": [ [ "/ai-strategy", "Revisit the investment case" ], [ "/ai-capability-planning", "Sequence capability gaps" ], [ "/ai-workforce-planning", "Plan training and delivery roles" ], [ "/ai-delivery-governance", "Define rollout gates" ], [ "/agentic-transformation", "Assess workflows involving agents" ], [ "/enterprise-ai-architecture", "Map technical dependencies" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-transformation.md", "markdown_sha256": "98c5d5e949b66f66ae43d36d5bc5c07679f23acc57d267a0586682cd7a8d4b22", "sha256": "e5c8d839226e6f9325277dbd8753ba2451fe75615034eba0d24bc07dbac0a3d6" }, { "id": "executive-ai-operating-model", "canonical_url": "https://teamstation.dev/ai-operating-model", "title": "An AI operating model makes ownership clear", "description": "Define AI product, platform, risk and service ownership. Compare centralized and federated models before scaling engineering delivery.", "direct_answer": "An AI operating model defines who decides, who delivers, and who supports AI work. The practical choice is how to divide responsibility between business teams, shared platforms, and independent risk oversight.", "decisions": [ [ "Centralized", "Useful when specialist skills or controls are scarce; watch for intake bottlenecks.", "Central AI lead" ], [ "Federated", "Useful when domains differ; require clear shared standards and service boundaries.", "Domain product owners" ], [ "Shared platform", "Centralize reusable services while domain teams own outcomes and workflow decisions.", "Platform and product leads" ] ], "steps": [ "List decisions that need a single enterprise owner, including access, provider policy, and shared services.", "Give each product an owner for business acceptance, budget, and exceptions.", "Define service agreements between platform and product teams, including escalation and change handling.", "Review waiting time and unresolved ownership conflicts, then adjust the boundaries." ], "evidence": { "id": "operating-model-decision-rights", "title": "Decision rights worksheet", "reference": "GOVERN 2.1", "premise": "NIST asks organizations to document risk roles and communication lines.", "columns": [ "Decision", "Accountable owner", "Record to retain" ], "rows": [ [ "Approve a use case", "Business product owner", "Outcome, scope, budget, and acceptance criteria." ], [ "Grant system access", "System or data owner", "Approved permissions and expiration or review date." ], [ "Accept residual risk", "Named risk authority", "Known limitations, mitigation, and decision rationale." ], [ "Restore service", "Service owner", "Runbook, escalation path, and recovery test." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), GOVERN 2.1", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "This worksheet proposes responsibilities; it does not establish that a company has implemented them. Team size alone does not determine the best operating model.", "faqs": [ { "question": "Does every business need a central AI team?", "answer": "No. Centralize responsibilities that genuinely need shared expertise or control. Keep domain decisions with the people accountable for the business workflow." }, { "question": "Who owns an AI system after launch?", "answer": "Name a service owner before launch. Product, platform, security, and support teams need explicit responsibilities and an escalation path rather than assumed shared ownership." } ], "workflow": { "title": "Separate the decisions that teams own", "nodes": [ [ "Business owns outcomes", "The product owner sets priorities and accepts workflow results." ], [ "Platform owns shared services", "The platform team provides supported interfaces and operating limits." ], [ "Risk owns acceptance", "The authorized risk owner decides on documented exceptions." ] ] }, "scenario": { "title": "Three departments need the same model gateway", "situation": "Three business units want AI features, each with a different workflow and release schedule. A central team can operate identity, model access and logging, but it shouldn't become the owner of every domain decision. Leaving everything local creates a different problem: duplicated controls and unclear support.", "options": [ [ "Central delivery", "Use a central team for a bounded early workload when specialist capacity is scarce. Make the intake queue visible." ], [ "Shared platform", "Offer common interfaces and controls while business teams own their workflows, evaluation and budgets." ], [ "Domain delivery", "Give teams local responsibility where requirements differ, with explicit shared security and service contracts." ] ], "decision": "Record who may change an interface, accept a failed evaluation or restore service. Track waiting time at those boundaries. If ownership is shared, name who makes the final decision rather than relying on a committee label." }, "engagement": { "fit": "Use a delivery engagement to fill an explicit team boundary, not an undefined promise to own all AI. We can scope distributed engineering roles against your product and platform responsibilities.", "deliverables": [ "A responsibility map for delivery, review, access and production support.", "Documented handoffs and escalation expectations.", "Role and coverage requirements tied to the agreed service boundary." ], "boundary": "Your organization retains its business priorities and risk authority. A delivery team should not silently inherit permission to accept enterprise risk." }, "connections": [ { "text": "The ownership split determines which roles belong in the team and which remain shared services.", "link": [ "/ai-workforce-planning", "Build the workforce plan from responsibilities" ] }, { "text": "Architecture should show the same product and platform boundaries that the operating model assigns.", "link": [ "/enterprise-ai-architecture", "Map the shared service interfaces" ] } ], "next_step": [ "/ai-workforce-planning", "Translate responsibilities into roles" ], "related_links": [ [ "/ai-strategy", "Tie ownership to investment decisions" ], [ "/ai-transformation", "Plan the organizational transition" ], [ "/ai-governance", "Separate delivery ownership from risk approval" ], [ "/ai-delivery-governance", "Make release decisions explicit" ], [ "/enterprise-ai-architecture", "Define platform boundaries" ], [ "/ai-capacity-planning", "Fund shared operating work" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-operating-model.md", "markdown_sha256": "5c3e32be941433b8aea5ffcbe6afa102ba93aaed42645759c92900f830689eb8", "sha256": "913f3b447dd7a731ad6eba96680b37928ddb768bbaaeff6f40305264f0823ec5" }, { "id": "executive-ai-capability-planning", "canonical_url": "https://teamstation.dev/ai-capability-planning", "title": "AI capability planning finds the missing pieces", "description": "Assess AI skills, data access, integration, evaluation and operations. Sequence evidence-backed capability gaps before adding teams.", "direct_answer": "AI capability planning compares what a workflow requires with what your organization can actually deliver and support. It covers data, integration, evaluation, security, and operating skills, not just model development.", "decisions": [ [ "Current ability", "Ask for a recent work sample or operational record, not a skills label alone.", "Engineering lead" ], [ "Dependency", "Identify the upstream permission, dataset, service, or owner that limits progress.", "Architecture and data leads" ], [ "Gap response", "Choose training, reassignment, managed delivery, or a narrower scope.", "Capability owner" ] ], "steps": [ "Break the use case into tasks from data intake through support.", "Record the evidence that a team can perform each task safely.", "Mark missing evidence separately from a demonstrated skill gap.", "Sequence the limiting dependencies first and reassess with a practical work sample." ], "evidence": { "id": "capability-evidence-map", "title": "Capability evidence map", "reference": "MAP 1.2", "premise": "NIST includes competencies and capacity when establishing system context.", "columns": [ "Capability", "Useful evidence", "Dependency to check" ], "rows": [ [ "Retrieval", "A traceable answer linked to permitted source documents.", "Data owner and access policy." ], [ "Evaluation", "A versioned test set with expected behavior and failure cases.", "Domain reviewer availability." ], [ "Operations", "A monitored service with an exercised recovery path.", "Deployment access and support coverage." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), MAP 1.2", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "A missing artifact means readiness is unverified, not that a person lacks ability. Assess the actual task and avoid treating a capability checklist as a universal score.", "faqs": [ { "question": "Is an AI capability gap the same as a hiring gap?", "answer": "No. A gap can be missing data access, unclear ownership, weak evaluation, or an integration constraint. Hiring is only one possible response." }, { "question": "How should capability readiness be verified?", "answer": "Use task-specific work samples, system records, and practical tests. Record unknowns separately from failed checks and revisit them when evidence becomes available." } ], "workflow": { "title": "Turn a capability claim into observable evidence", "nodes": [ [ "Name the task", "Describe the work the system and team must perform." ], [ "Inspect the evidence", "Check a work sample, test result or operating record." ], [ "Close the real gap", "Address missing skills, access or platform support separately." ] ] }, "scenario": { "title": "Is a retrieval problem really a hiring problem?", "situation": "An internal knowledge assistant returns weak answers. The team asks for more AI engineers, but the source documents have conflicting owners and stale permissions. Another specialist might improve retrieval, yet cannot decide who is allowed to see each document or which version is authoritative.", "options": [ [ "Fix the data dependency", "Assign source ownership, permission rules and freshness expectations before tuning retrieval." ], [ "Develop the skill", "Use a bounded work sample and supported practice when the team lacks evaluation or retrieval experience." ], [ "Add delivery capacity", "Add a role when the task is understood, access is ready and current capacity cannot cover it." ] ], "decision": "Keep unknown readiness separate from demonstrated inability. Ask the team to produce a traceable answer, a denied-access test and an explanation of a failed result. Those artifacts reveal more than a list of tools on a skills matrix." }, "engagement": { "fit": "Bring a workflow and the evidence you already have. We can help translate the missing engineering work into role requirements and a bounded delivery scope.", "deliverables": [ "A task-to-capability map with evidence and missing dependencies.", "Practical role requirements tied to implementation and review work.", "A sequence for training, platform repair and additional capacity." ], "boundary": "A capability map isn't a validated score of employee potential. Missing evidence calls for further assessment, not an automatic hiring or replacement decision." }, "connections": [ { "text": "Once the missing capability is clear, decide whether to develop it internally or add a delivery role.", "link": [ "/ai-workforce-planning", "Compare workforce options" ] }, { "text": "If the missing capability is a shared service, define its interface and owner before staffing around it.", "link": [ "/enterprise-ai-architecture", "Review architecture dependencies" ] } ], "next_step": [ "/ai-workforce-planning", "Build the role plan around confirmed gaps" ], "related_links": [ [ "/ai-strategy", "Check which capabilities deserve investment" ], [ "/ai-transformation", "Sequence capability development" ], [ "/ai-operating-model", "Assign capability ownership" ], [ "/ai-capacity-planning", "Budget for training and review time" ], [ "/enterprise-ai-architecture", "Find platform dependencies" ], [ "/agentic-transformation", "Assess the skills needed for agent tool use" ], [ "/hire/by-role/data-engineer", "Review data engineering responsibilities" ], [ "/hire/by-technology/python", "Review Python delivery needs" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-capability-planning.md", "markdown_sha256": "583b0fcb71aa9dbcbc2b89b1f102bab5e7ae4e5218799f889f9bdab098acbcd5", "sha256": "afe00b7274e93c22f7dc6ca75bde4e4f48ca8e5808611d9c90622dbcd3caaf80" }, { "id": "executive-ai-workforce-planning", "canonical_url": "https://teamstation.dev/ai-workforce-planning", "title": "Plan AI teams around the work they must own", "description": "Plan AI engineering roles, seniority, review coverage and sourcing from real delivery work, then estimate monthly seats with TeamStation.", "direct_answer": "AI workforce planning turns a delivery plan into roles, seniority, skills development, and sourcing choices. Start with the work that people must own, including review and support, before deciding how many seats to add.", "decisions": [ [ "Role mix", "Cover product decisions, data, implementation, evaluation, and operations.", "Engineering manager" ], [ "Seniority", "Match ambiguity, production authority, mentoring, and review duties to demonstrated experience.", "Technical lead" ], [ "Sourcing", "Compare internal development and managed capacity against continuity, overlap, and access needs.", "Engineering and procurement owners" ] ], "steps": [ "List recurring work and the decisions that require accountable people.", "Map current team strengths and identify tasks without an owner or backup.", "Choose a role mix, training plan, review coverage, and sourcing model.", "Price the actual seat plan, then validate onboarding, access, time overlap, and support coverage." ], "evidence": { "id": "workforce-role-coverage", "title": "Role coverage and validation path", "reference": "GOVERN 2.2", "premise": "NIST includes risk management training for personnel and partners.", "columns": [ "Work to cover", "Validation task", "Coverage decision" ], "rows": [ [ "Data access and preparation", "Explain data permissions and demonstrate a reproducible preparation step.", "Name a data owner and engineering backup." ], [ "AI implementation", "Change a bounded feature and explain its failure modes.", "Match seniority to decision complexity." ], [ "Evaluation and release", "Review failed cases independently and explain the release decision.", "Protect reviewer capacity rather than assuming it is free." ], [ "Production support", "Work through a failed dependency and recovery scenario.", "Assign operating hours and escalation coverage." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), GOVERN 2.2", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "This is a role validation method, not a claim about any candidate or customer result. AI adoption alone does not prove that fewer engineers are needed.", "faqs": [ { "question": "How many engineers should an AI team have?", "answer": "There is no universal team size. Define the workload, role coverage, review needs, support obligations, and available capacity before choosing seat counts." }, { "question": "What is the difference between workforce and capacity planning?", "answer": "Workforce planning selects roles, skills, seniority, and sourcing. Capacity planning checks whether that team has enough available time and budget for the committed work." } ], "workflow": { "title": "Work first, roles second, seats third", "nodes": [ [ "Describe the work", "Separate implementation, evaluation, integration and support." ], [ "Assign role coverage", "Match decision complexity, skills and review responsibility." ], [ "Choose the sourcing plan", "Compare internal development, reassignment and managed delivery." ] ] }, "scenario": { "title": "A model engineer cannot cover every delivery role", "situation": "A company plans an AI feature inside an existing customer application. Model integration is only one part of the work. Someone must maintain data access, update the application, review incorrect outputs and support the feature after launch. Counting only model-building work understates the team requirement.", "options": [ [ "Develop existing staff", "Choose training and supported practice where the team has adjacent skills and time to learn." ], [ "Reassign experienced staff", "Move people when the required capability exists, while accounting for the work they leave behind." ], [ "Add managed seats", "Add defined engineering coverage when the work, seniority and delivery responsibilities are clear." ] ], "decision": "Keep an accountable domain reviewer and production owner in the plan. Compare sourcing choices using the same work scope, support coverage and acceptance criteria. Don't turn an AI tooling decision into an unsupported headcount-reduction target." }, "engagement": { "fit": "TeamStation scopes managed nearshore engineering seats around the work and seniority required. Bring the backlog, review responsibilities, time-zone needs and operating coverage before selecting a team.", "deliverables": [ "A role and seniority plan tied to actual delivery tasks.", "An explicit split between implementation, independent review and support.", "A monthly engineering-seat scenario using the existing capacity planner." ], "boundary": "An estimate is not a signed offer or proof of availability. Confirm scope and commercial terms separately; no salary ranges or productivity savings are inferred here." }, "connections": [ { "text": "A role plan still needs a workload check, because support and review consume the same finite capacity.", "link": [ "/ai-capacity-planning", "Check workload against team capacity" ] }, { "text": "Use the role-based planner for monthly seat estimates rather than importing a salary comparison.", "link": [ "/pricing/capacity-planner", "Estimate the engineering seats in your plan" ] } ], "next_step": [ "/pricing/capacity-planner", "Price the roles and seats in your plan" ], "related_links": [ [ "/ai-strategy", "Confirm the business objective" ], [ "/ai-capability-planning", "Distinguish skills gaps from platform gaps" ], [ "/ai-operating-model", "Assign decision rights" ], [ "/ai-capacity-planning", "Check workload against available capacity" ], [ "/ai-delivery-governance", "Reserve review and release coverage" ], [ "/hire/by-role/ai-platform-engineer", "Review AI platform engineering responsibilities" ], [ "/hire/by-country/mexico", "Evaluate a LATAM delivery location" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-workforce-planning.md", "markdown_sha256": "0dc4bc2224431d5304e942c6ec9f9b082dc2bd86c604c8d0db4778f71cf423e4", "sha256": "119e3889261d7604692942ca7a49264b612e14b456d06b289bd85a3e255a526a" }, { "id": "executive-ai-governance", "canonical_url": "https://teamstation.dev/ai-governance", "title": "AI governance puts responsibility before access", "description": "Set AI data permissions, action limits, risk ownership and review triggers. Connect written policy to controls teams can test.", "direct_answer": "AI governance defines what a system may do, who can authorize it, and how its risks are reviewed. It connects policy to real access controls, accountable decisions, and evidence throughout the system lifecycle.", "decisions": [ [ "Data boundary", "Identify permitted sources, recipients, retention, and sensitive data restrictions.", "Data owner and security lead" ], [ "Decision authority", "Specify which actions need approval and who may grant it.", "Business risk owner" ], [ "Oversight", "Set review triggers for changed models, workflows, data, and incidents.", "Governance owner" ] ], "steps": [ "Inventory the AI systems and intended uses, including third-party services.", "Classify risks with the business, security, privacy, and legal owners where needed.", "Implement access and approval boundaries, then test denied as well as allowed actions.", "Retain decision records and review the controls after meaningful changes or incidents." ], "evidence": { "id": "governance-control-register", "title": "Control evidence register", "reference": "GOVERN 1.6", "premise": "NIST includes an AI system inventory informed by risk priorities.", "columns": [ "Control", "Evidence to inspect", "Review trigger" ], "rows": [ [ "System inventory", "Owner, purpose, data sources, provider, and current operating status.", "A new use case or provider." ], [ "Least privilege", "Permission scope plus tests of prohibited access.", "A role, tool, or data change." ], [ "Approval boundary", "A recorded decision tied to the exact action and approver.", "Expanded autonomy or scope." ], [ "Incident response", "Escalation record, containment action, and recovery evidence.", "A harmful or unexpected result." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), GOVERN 1.6", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "These controls are planning guidance, not a legal determination or certification. Applicable requirements depend on the jurisdiction, data, system use, and agreement.", "faqs": [ { "question": "Is AI governance only a policy exercise?", "answer": "No. Policy needs enforceable access controls, approval paths, testing, monitoring, and accountable owners. A written rule alone does not demonstrate that a control works." }, { "question": "Does following this guide establish compliance?", "answer": "No. Compliance depends on applicable requirements and verified implementation. This guide does not establish certification or legal compliance." } ], "workflow": { "title": "Policy needs an enforceable boundary", "nodes": [ [ "Define permitted use", "Name the system, purpose, data and accountable owner." ], [ "Enforce the limit", "Apply access controls and approval requirements to actual actions." ], [ "Review what changed", "Reassess after new data, tools, scope or incidents." ] ] }, "scenario": { "title": "A sales assistant can read records, but can it change them?", "situation": "A sales assistant summarizes customer records for an account team. The proposed next step is to update those records automatically. Reading and changing a record carry different consequences, and access to the CRM doesn't itself authorize every action the assistant can perform.", "options": [ [ "Read-only assistance", "Restrict the service to permitted records and keep output separate from system changes." ], [ "Approved changes", "Require an authorized person to approve the exact record and proposed change." ], [ "Bounded automation", "Consider limited actions only after denied-action, duplicate and recovery tests support the agreed risk boundary." ] ], "decision": "Name who can accept the remaining risk and who can revoke access. Preserve a record of the decision and the tested control. A successful allowed action isn't enough; test the actions the system must refuse as well." }, "engagement": { "fit": "We can scope governance engineering as implemented access, evaluation and delivery controls. Your security, privacy and business owners define the policy and retain risk acceptance.", "deliverables": [ "A control backlog tied to real systems and accountable owners.", "Allowed and denied behavior tests with retained results.", "Review triggers and an incident escalation path." ], "boundary": "This is engineering guidance, not a legal opinion, certification or assurance that a particular control satisfies every applicable obligation." }, "connections": [ { "text": "Governance defines the rule; delivery governance checks that the exact release still follows it.", "link": [ "/ai-delivery-governance", "Bind controls to release evidence" ] }, { "text": "Agents need action-specific limits because a tool call can create an external effect.", "link": [ "/agentic-transformation", "Separate agent capability from authority" ] } ], "next_step": [ "/ai-delivery-governance", "Turn policy into release and operating checks" ], "related_links": [ [ "/ai-strategy", "Set investment risk tolerance" ], [ "/ai-operating-model", "Assign accountable decision makers" ], [ "/ai-workforce-planning", "Plan trained review coverage" ], [ "/agentic-transformation", "Set agent action boundaries" ], [ "/enterprise-ai-architecture", "Trace security and data boundaries" ], [ "/trust-center", "Review TeamStation trust information" ], [ "/hire/by-role/ai-governance-engineer", "Review governance engineering responsibilities" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-governance.md", "markdown_sha256": "03dcf3f572088fb73b2d28faacfcfc956e30c8f7fd3359d1c62d9d0593f51624", "sha256": "02f5c2c4a4c148a8c71dab12f4c4a0a91030c7144264c1bd83a271af3ef80479" }, { "id": "executive-ai-delivery-governance", "canonical_url": "https://teamstation.dev/ai-delivery-governance", "title": "AI delivery governance makes releases accountable", "description": "Bind AI evaluations, review, release approval and recovery to the exact version shipped, with clear owners and production readback.", "direct_answer": "AI delivery governance turns policy into checks on the work being shipped. It binds evaluations, approval, deployment, and monitoring to the exact version of a system, rather than a result from an earlier build.", "decisions": [ [ "Evaluation", "Test intended behavior, denied actions, and important failure cases.", "Evaluation and domain owners" ], [ "Release", "Match review and test evidence to the exact candidate.", "Release owner" ], [ "Operation", "Define monitoring, rollback conditions, and escalation ownership.", "Service owner" ] ], "steps": [ "Freeze the intended behavior and failure boundaries for the candidate.", "Run representative evaluations and regressions, recording the version and limitations.", "Require an authorized release decision on that exact candidate and a tested recovery path.", "Verify the deployed version and monitor business exceptions as well as technical failures." ], "evidence": { "id": "delivery-release-evidence", "title": "Release evidence checklist", "reference": "MEASURE 2.1", "premise": "NIST calls for documented test sets, metrics, and evaluation tools.", "columns": [ "Release artifact", "Required binding", "Failure action" ], "rows": [ [ "Evaluation results", "Candidate version, test set, environment, and observed failures.", "Resolve failures or record an authorized scope reduction." ], [ "Review", "Reviewer and exact reviewed change.", "Re-review when relevant content changes." ], [ "Recovery check", "Known recovery target and conditions for using it.", "Do not release without a usable recovery path." ], [ "Production readback", "Observed deployed version and key operating checks.", "Investigate mismatch before calling the release complete." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), MEASURE 2.1", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "Passing a finite test set does not prove that all future behavior is safe. Preserve known limits and monitor conditions not represented in the evaluation.", "faqs": [ { "question": "When does an AI release need a new review?", "answer": "When a change affects the reviewed behavior, data, permissions, model, prompt, tools, or operating environment. Evidence must match the candidate being released." }, { "question": "Are model evaluations enough to approve a release?", "answer": "No. Check integrations, access controls, user workflows, operating behavior, recovery, and the exact deployed version as well as model outputs." } ], "workflow": { "title": "Evidence must follow the release candidate", "nodes": [ [ "Freeze the candidate", "Identify the code, prompts, model, tools and data configuration." ], [ "Evaluate and review", "Test expected behavior, regressions and denied actions." ], [ "Release and verify", "Check the deployed version and monitor the agreed boundaries." ] ] }, "scenario": { "title": "The prompt changed after the review passed", "situation": "An AI service passed evaluation, then a prompt and retrieval setting changed before deployment. The previous report describes a different candidate. The change might be small in code, yet it can alter which documents are retrieved, how an answer is formed or when a tool is called.", "options": [ [ "Re-run affected checks", "Trace the changed behavior and repeat its evaluation plus the relevant regressions." ], [ "Reduce the release scope", "Leave the unverified behavior out of the candidate with a clear, authorized scope decision." ], [ "Hold the release", "Stop when critical failures, stale review or an untested recovery path remain unresolved." ] ], "decision": "Record the candidate identity with each test and review. After deployment, read back the actual version and exercise the critical flow. A successful build or upload doesn't establish that users received the reviewed behavior." }, "engagement": { "fit": "We can scope the engineering work behind repeatable release checks and operational handover. Start with your current delivery pipeline and its known failure modes.", "deliverables": [ "Version-bound evaluation and regression checks.", "Explicit review, release and recovery ownership.", "Production verification and monitoring tasks in the delivery backlog." ], "boundary": "No finite test suite proves unrestricted safety. Keep known gaps visible, and do not describe a planning checklist as an independently completed audit." }, "connections": [ { "text": "Release checks need time and people, so include evaluation and recovery work in the capacity plan.", "link": [ "/ai-capacity-planning", "Reserve review and operating capacity" ] }, { "text": "The architecture determines which dependencies and failure paths a release must exercise.", "link": [ "/enterprise-ai-architecture", "Trace the production request path" ] } ], "next_step": [ "/ai-governance", "Confirm who may accept remaining risk" ], "related_links": [ [ "/ai-transformation", "Connect release gates to rollout stages" ], [ "/ai-operating-model", "Assign release and service ownership" ], [ "/ai-capability-planning", "Check evaluation capability" ], [ "/ai-capacity-planning", "Budget for review and support" ], [ "/agentic-transformation", "Test tool actions and approvals" ], [ "/engineering-telemetry-and-node-intelligence", "Review delivery telemetry methods" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-delivery-governance.md", "markdown_sha256": "8bcf3fca46d13c76534dc1171a71b0f7a96a8c9c5c1a7cdd032f9f8fd19d4399", "sha256": "ba775a0ec0a18185437633b91989049376ffa385e5d3235595e4698fff73cbfa" }, { "id": "executive-ai-capacity-planning", "canonical_url": "https://teamstation.dev/ai-capacity-planning", "title": "Match AI delivery commitments to real capacity", "description": "Compare delivery demand with engineering, review and support capacity. Build monthly role-based seat estimates without invented savings.", "direct_answer": "AI capacity planning checks whether available engineering, review, and support time can cover the committed workload. Budget scenarios should use the actual role and seat plan, not an invented salary range or assumed productivity gain.", "decisions": [ [ "Demand", "Separate new delivery from incidents, review, and operating work.", "Delivery owner" ], [ "Constraint", "Find the role or dependency that limits completion, not just the busiest person.", "Engineering lead" ], [ "Budget", "Compare explicit role, level, market, seat, and duration scenarios.", "Finance and engineering owners" ] ], "steps": [ "Describe the committed work and the skills needed to complete and review it.", "Record available coverage after existing support and other obligations.", "Test a reduced scope, a changed sequence, and an additional-seat scenario against the same constraint.", "Use the existing capacity planner for the seat estimate, then validate assumptions and final commercial terms." ], "evidence": { "id": "capacity-scenario-record", "title": "Capacity scenario record", "reference": "MAP 3.2", "premise": "NIST includes the costs of system behavior and errors.", "columns": [ "Scenario input", "Evidence required", "What not to assume" ], "rows": [ [ "Delivery demand", "Prioritized work, dependencies, and acceptance requirements.", "A backlog count is not a reliable effort estimate." ], [ "Available coverage", "Role availability, review load, support, leave, and training.", "Every paid hour is not feature delivery time." ], [ "Monthly seat budget", "Saved role, level, market, seat count, and duration from the capacity planner.", "A planning estimate is not a signed price or demonstrated savings." ], [ "Non-seat costs", "Provider, infrastructure, integration, and operating costs recorded separately.", "Engineering seat totals do not include every project cost." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), MAP 3.2", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "This page does not calculate prices. The linked planner supplies seat estimates; final terms require an approved offer. No AWS commitment eligibility or savings follows from a capacity scenario.", "faqs": [ { "question": "How do I calculate the monthly team estimate?", "answer": "Use the TeamStation capacity planner to select role, level, delivery market, seat count, and duration. It sums the seat estimates; this guide does not substitute its own rates." }, { "question": "Does a seat estimate prove the team can meet a deadline?", "answer": "No. Validate workload, dependencies, review coverage, support obligations, and actual availability separately. Price and delivery capacity are different decisions." } ], "workflow": { "title": "A budget buys seats, not unlimited throughput", "nodes": [ [ "Measure demand", "Include delivery, review, incidents and ongoing support." ], [ "Find the constraint", "Check available coverage and blocked dependencies." ], [ "Price the scenario", "Use the actual role-based seat plan and separate non-seat costs." ] ] }, "scenario": { "title": "More implementation capacity, the same review queue", "situation": "A delivery team can complete changes faster than a domain expert can review them. The backlog is growing, but adding another implementation seat could increase waiting rather than increase accepted work. The capacity decision depends on the constrained stage, not just total engineering headcount.", "options": [ [ "Reduce work in progress", "Finish and review fewer items at once before starting more implementation." ], [ "Increase review coverage", "Allocate qualified reviewer time and improve the evidence supplied for each decision." ], [ "Add an engineering seat", "Add implementation capacity only when review, dependencies and support can absorb the work." ] ], "decision": "Compare accepted work, review waiting and rework over a stated period. Price each seat scenario with the TeamStation calculator, keeping its selected roles and assumptions. Record cloud usage and other project costs separately without double-counting items already included in the managed seat." }, "engagement": { "fit": "Bring the delivery workload, existing support commitments and required role mix. We can use those inputs to scope managed engineering capacity and a monthly seat estimate.", "deliverables": [ "A demand and coverage map for delivery, review and support.", "Alternative scope, sequencing and seat scenarios.", "A saved calculator scenario with explicit role and monthly-unit assumptions." ], "boundary": "This guide contains no alternative pricing formula. The capacity planner provides estimates; final offers, workload feasibility and any AWS commitment eligibility require separate confirmation." }, "connections": [ { "text": "If the role mix is still unclear, resolve responsibilities and seniority before comparing seat totals.", "link": [ "/ai-workforce-planning", "Define the team roles" ] }, { "text": "Once the role mix is explicit, calculate the monthly seat estimate in the existing planner.", "link": [ "/pricing/capacity-planner", "Open the TeamStation capacity planner" ] } ], "next_step": [ "/pricing/capacity-planner", "Build a role-based monthly seat estimate" ], "related_links": [ [ "/ai-strategy", "Check the investment priority" ], [ "/ai-workforce-planning", "Define the roles before counting seats" ], [ "/ai-capability-planning", "Identify training and platform constraints" ], [ "/ai-transformation", "Sequence the rollout" ], [ "/ai-delivery-governance", "Reserve evaluation and release capacity" ], [ "/pricing", "Review pricing scope and terms" ] ], "markdown_url": "https://teamstation.dev/markdown/ai-capacity-planning.md", "markdown_sha256": "8f05aee52a5fbd82bf4ee3e84568aa4499349ad676f1bb2f82934f379b53611c", "sha256": "550214bff84fe0293ffe3428c473369127ccce2f4103452cd5163c38abd665a3" }, { "id": "executive-agentic-transformation", "canonical_url": "https://teamstation.dev/agentic-transformation", "title": "Give AI agents bounded work, not open authority", "description": "Plan agent workflows with bounded tool access, action-specific approval, evaluation and recovery before expanding automation.", "direct_answer": "Agentic transformation redesigns a workflow so software agents can perform bounded tasks with tools. People still define authority, approve sensitive actions, own outcomes, and handle exceptions the system cannot safely resolve.", "decisions": [ [ "Read and recommend", "Keep tools read-only when the task only needs analysis or a draft.", "Workflow owner" ], [ "Act with approval", "Bind approval to the exact action, destination, and scope.", "Authorized business approver" ], [ "Bounded automation", "Require tested limits, deduplication, monitoring, and recovery before unattended actions.", "Service and security owners" ] ], "steps": [ "Choose a repeatable workflow and separate observation, recommendation, approval, and execution.", "Define allowed tools, inputs, destinations, and actions that must stop for approval.", "Test denied actions, repeated requests, stale approvals, failed tools, and uncertain outcomes.", "Expand authority only when observed behavior supports it, keeping a clear stop and recovery path." ], "evidence": { "id": "agent-authority-transition", "title": "Agent action boundary test", "reference": "GOVERN 3.2", "premise": "NIST distinguishes human and AI roles and oversight responsibilities.", "columns": [ "Transition", "Test to run", "Evidence to retain" ], "rows": [ [ "Read to draft", "Confirm that drafting cannot send or mutate records.", "Allowed and denied tool results." ], [ "Draft to approved action", "Change the destination after approval and confirm execution is rejected.", "Action and approval scope." ], [ "Action to retry", "Simulate an uncertain outcome and reconcile before another attempt.", "Original request identity and readback." ], [ "Failure to recovery", "Exercise a stop, escalation, and authorized recovery.", "Owner, observed state, and recovery result." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), GOVERN 3.2", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "These are recommended test scenarios, not a claim that a particular agent has passed them. A successful demonstration does not justify unrestricted autonomy.", "faqs": [ { "question": "Does agentic AI mean removing human approval?", "answer": "No. Approval requirements depend on the action and risk. Sensitive actions need explicit authority even when an agent can technically perform them." }, { "question": "What should happen after an uncertain tool result?", "answer": "Check the resulting state before retrying. An uncertain response is not proof that an action failed, and a blind retry can duplicate an external effect." } ], "workflow": { "title": "Separate observation from action", "nodes": [ [ "Observe and propose", "Read permitted information and prepare a proposed action." ], [ "Check authority", "Validate the exact action, destination, scope and approval." ], [ "Act and reconcile", "Execute once, inspect the result and resolve uncertainty before retrying." ] ] }, "scenario": { "title": "An agent opens a support ticket, then the connection drops", "situation": "An agent submits a support ticket and receives a timeout. The ticket may already exist. Automatically repeating the request can create a duplicate, while treating the timeout as success can hide a missing ticket. The workflow needs a defined way to resolve that uncertainty.", "options": [ [ "Read back the result", "Look up the original request identity or destination record before another write." ], [ "Use duplicate protection", "Where supported, bind the action to an idempotency key and verify the destination behavior." ], [ "Escalate uncertainty", "Stop further writes when the outcome cannot be established, preserving evidence for the responsible owner." ] ], "decision": "Test success, rejection, timeout and replay as separate cases. Approval for one action doesn't authorize a changed recipient or broader action. Expand autonomy only for a tested task boundary with a clear owner and recovery route." }, "engagement": { "fit": "We can scope agent engineering around specific tools and permitted workflows. Bring the intended action, its business consequence and the systems that can confirm the result.", "deliverables": [ "A tool and action permission map.", "Evaluation cases for rejection, replay, stale approval and uncertain outcomes.", "A monitored workflow with explicit stop and recovery behavior." ], "boundary": "An agent's technical ability is not business authorization. The example is a proposed engineering pattern, not a claim that every integration supports idempotency or automatic recovery." }, "connections": [ { "text": "Tool permissions should follow the same enterprise risk ownership as the rest of the workflow.", "link": [ "/ai-governance", "Define action and approval boundaries" ] }, { "text": "Trace the destination systems and their failure behavior before automating writes.", "link": [ "/enterprise-ai-architecture", "Review agent integration architecture" ] } ], "next_step": [ "/enterprise-ai-architecture", "Map agent tools and security boundaries" ], "related_links": [ [ "/ai-strategy", "Check whether an agent is needed" ], [ "/ai-transformation", "Plan the workflow change" ], [ "/ai-operating-model", "Assign human accountability" ], [ "/ai-governance", "Define permissions and approvals" ], [ "/ai-delivery-governance", "Bind evaluations to releases" ], [ "/hire/by-role/agentic-systems-engineer", "Review agent engineering responsibilities" ] ], "markdown_url": "https://teamstation.dev/markdown/agentic-transformation.md", "markdown_sha256": "d3b13bad57cda03ab2120733646c84fb8cb623854d9b3fa5e0e8eae046bff2f8", "sha256": "feb22d5ccf67ca0594ff6d0b0b56fcb782194938a00f18c126fdaa8094e9c9ca" }, { "id": "executive-enterprise-ai-architecture", "canonical_url": "https://teamstation.dev/enterprise-ai-architecture", "title": "Enterprise AI architecture follows the data", "description": "Trace AI data, models, tools and integrations across trust boundaries. Define access, evaluation, cost and recovery before scaling.", "direct_answer": "Enterprise AI architecture defines how data, models, applications, and tools connect across security and ownership boundaries. Start with the request path and failure behavior, then choose the components needed to support it.", "decisions": [ [ "Data path", "Trace permitted sources, transformations, retrieval, and destinations.", "Data and architecture owners" ], [ "Integration", "Define contracts, authorization, timeouts, and failure behavior for each dependency.", "Platform and application leads" ], [ "Operation", "Measure latency, failure, cost, and quality with a recovery plan.", "Service owner" ] ], "steps": [ "Draw one request from user input through retrieval, model access, tool use, and response.", "Mark identity, authorization, sensitive data, persistence, and third-party boundaries.", "Define evaluation, dependency failure, recovery, and operating budgets before expanding scope.", "Review the deployed path against the design, including traces, denied access, and provider failures." ], "evidence": { "id": "architecture-boundary-record", "title": "Request-path boundary record", "reference": "MAP 4.2", "premise": "NIST includes risk controls for system components and third-party technology.", "columns": [ "Boundary", "Contract to define", "Verification evidence" ], "rows": [ [ "User to application", "Identity, authorization, input validation, and retention.", "Allowed and denied requests." ], [ "Application to retrieval", "Source permissions, freshness, and document provenance.", "Answer traces and access isolation tests." ], [ "Application to provider or tool", "Permitted data, action scope, timeout, and retry behavior.", "Failure injection and duplicate-action checks." ], [ "Service to operations", "Quality, cost, latency, alert ownership, and recovery.", "Trace records and a recovery exercise." ] ], "source": "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/", "sourceTitle": "NIST AI RMF 1.0 (2023), MAP 4.2", "boundary": "TeamStation planning worksheet informed by the cited reference, not a customer result, certification, or completed assessment." }, "limitations": "This reference path is illustrative, not a production architecture or security assessment. Components and controls must fit the actual workload and data obligations.", "faqs": [ { "question": "Should enterprise AI architecture start with a model choice?", "answer": "Start with the workload, data permissions, integration boundaries, and operating requirements. Choose a model and provider that fit those constraints." }, { "question": "What belongs in an AI architecture review?", "answer": "Review the request path, data access, third-party dependencies, evaluation coverage, failure handling, operating cost, observability, and accountable service ownership." } ], "workflow": { "title": "Trace one request across its trust boundaries", "nodes": [ [ "Identity and retrieval", "Authenticate the user and retrieve only permitted sources." ], [ "Model and tool access", "Constrain provider data and authorize each tool action." ], [ "Response and operations", "Return traceable output, monitor failures and retain only permitted data." ] ] }, "scenario": { "title": "An internal assistant spans two permission systems", "situation": "An assistant searches company documents and queries a customer system. A user may have access to one source but not the other. A single application login doesn't prove that every retrieved document or downstream record is permitted, and logging the response can create another copy of sensitive information.", "options": [ [ "Enforce source access", "Preserve the requesting identity and apply permission checks at retrieval and destination boundaries." ], [ "Constrain provider traffic", "Define which fields may leave the application and what the provider may retain." ], [ "Design failure behavior", "Use explicit timeouts, safe retries and a supported response when a dependency is unavailable." ] ], "decision": "Review the deployed request path, not just the component diagram. Exercise denied access and dependency failure, then check traces without exposing protected data. Include evaluation, latency and operating cost in the architecture decision record." }, "engagement": { "fit": "We can scope implementation roles around a defined request path, integration contracts and operating requirements. Bring your existing architecture and the owners of its critical dependencies.", "deliverables": [ "A request-path map with data and authority boundaries.", "Integration and evaluation work tied to accountable engineering roles.", "Deployment, monitoring and recovery requirements for the service." ], "boundary": "The diagram is a planning model, not a security certification or an approved production design. Validate actual provider behavior, data obligations and workload requirements." }, "connections": [ { "text": "Architecture exposes the work; capability planning checks whether the team can deliver and support it.", "link": [ "/ai-capability-planning", "Assess the required engineering capabilities" ] }, { "text": "Turn failure paths and access boundaries into version-bound release checks.", "link": [ "/ai-delivery-governance", "Plan architecture verification at release" ] } ], "next_step": [ "/ai-capability-planning", "Map the capabilities needed to deliver the architecture" ], "related_links": [ [ "/ai-strategy", "Tie architectural choices to business value" ], [ "/ai-operating-model", "Assign platform and product ownership" ], [ "/ai-governance", "Specify data and access controls" ], [ "/ai-delivery-governance", "Plan validation and release evidence" ], [ "/agentic-transformation", "Define tool-action boundaries" ], [ "/hire/by-technology/mlops", "Review model operations capabilities" ], [ "/hire/by-role/ai-platform-engineer", "Review platform engineering roles" ] ], "markdown_url": "https://teamstation.dev/markdown/enterprise-ai-architecture.md", "markdown_sha256": "7256401e14838bbd291b1622008e725dfa19fefb9e1f35ca8fb99c3b8e552912", "sha256": "bf55fc4f3d80594e5cde2c550e6137ae1449465dc697fe56965540b8bd7e7a36" } ], "sha256": "ddf3e128a4a78098bb0426a9107d1cc5e399556486c7cdd309bf73e565eb064c" }