{
  "schemaVersion": 1,
  "version": "2026-09-15",
  "id": "https://hk.onyxdevslab.com/data/ai-poc-to-production.json",
  "name": "AI proof-of-concept to production checklist",
  "datePublished": "2026-09-15",
  "dateModified": "2026-09-15",
  "evidenceClass": "Provider-authored implementation checklist",
  "publisher": {
    "name": "Onyx Devs Lab",
    "legalName": "ONYX DEVS LAB LIMITED",
    "url": "https://hk.onyxdevslab.com/",
    "leiCode": "254900Z30CLK7HKE9H46"
  },
  "landingPages": {
    "en": "https://hk.onyxdevslab.com/en/guides/ai-poc-to-production/",
    "zhHant": "https://hk.onyxdevslab.com/zh-hk/guides/ai-poc-to-production/",
    "zhHans": "https://hk.onyxdevslab.com/zh-cn/guides/ai-poc-to-production/"
  },
  "languages": {
    "en": {
      "name": "How does an AI proof of concept become a production system?",
      "summary": "A PoC proves a narrow technical question under controlled conditions. Production requires a complete operating workflow with representative evidence, real data and identity boundaries, reliable integration, accountable owners, recovery procedures, and an authority level that can be expanded safely.",
      "decisionSignals": [
        {
          "name": "PoC",
          "meaning": "Resolve one high-risk technical assumption"
        },
        {
          "name": "Pilot",
          "meaning": "Test the complete workflow with real operators"
        },
        {
          "name": "Production",
          "meaning": "Operate within signed controls and service levels"
        }
      ],
      "sections": [
        {
          "heading": "Close the gaps hidden by a demonstration",
          "introduction": "A demo often omits the states and responsibilities that dominate production work.",
          "checks": [
            {
              "name": "Representative quality",
              "requirement": "Replace selected examples with versioned common, edge, missing-data, adversarial, and high-impact cases, defined metrics, thresholds, and failure analysis."
            },
            {
              "name": "Enterprise boundaries",
              "requirement": "Connect real identities, tenants, permissions, systems of record, retention, audit, confirmation, and prohibited actions instead of shared test accounts."
            },
            {
              "name": "Operational completeness",
              "requirement": "Implement queues, retries, idempotency, state verification, latency and availability targets, monitoring, cost limits, fallbacks, incident response, and support."
            }
          ]
        },
        {
          "heading": "Turn a prototype into an owned service",
          "introduction": "Production begins when named teams can make and reverse operating decisions without depending on the demo authors.",
          "checks": [
            {
              "name": "Business ownership",
              "requirement": "Name the workflow owner, users, baseline, expected value, exception policy, adoption plan, funding, and authority to scale or stop."
            },
            {
              "name": "Technical ownership",
              "requirement": "Assign model, data, integration, security, release, observability, vendor, and recovery responsibilities with runbooks and escalation."
            },
            {
              "name": "Change evidence",
              "requirement": "Version prompts, models, retrieval, tools, policies, data, and tests; regression-test material changes and preserve release and rollback records."
            }
          ]
        }
      ],
      "procedure": [
        {
          "position": 1,
          "name": "Write the production gap register",
          "instruction": "Compare the PoC with the target workflow across users, data, permissions, integration, evaluation, operations, cost, ownership, and exit."
        },
        {
          "position": 2,
          "name": "Build one complete path",
          "instruction": "Implement the smallest end-to-end workflow, including exceptions, human review, resulting state, monitoring, and recovery."
        },
        {
          "position": 3,
          "name": "Run a controlled pilot",
          "instruction": "Limit users, volume, data, and authority; collect quality, reliability, cost, adoption, exception, and business evidence."
        },
        {
          "position": 4,
          "name": "Sign and stage the release",
          "instruction": "Approve only the tested scope and authority, record residual risks and stop conditions, and expand after the agreed evidence window."
        }
      ],
      "frequentlyAskedQuestions": [
        {
          "question": "When is a PoC successful?",
          "answer": "When it answers the specific uncertainty it was designed to test. That does not automatically make the solution production-ready or worth scaling."
        },
        {
          "question": "Should the PoC code be reused?",
          "answer": "Only after reviewing architecture, security, tests, dependencies, licences, data handling, observability, and maintainability. Reuse is an engineering decision, not a default."
        },
        {
          "question": "What most often blocks production?",
          "answer": "Unclear ownership, unrepresentative evaluation, weak data and identity controls, incomplete integration, missing failure handling, and no credible operating economics."
        }
      ]
    },
    "zhHant": {
      "name": "AI 概念驗證如何變成生產系統？",
      "summary": "PoC 在受控條件下證明一個狹窄技術問題。生產則需要完整營運流程、代表性證據、真實數據與身份邊界、可靠整合、問責負責人、恢復程序，以及可以安全擴大的權限層級。",
      "decisionSignals": [
        {
          "name": "PoC",
          "meaning": "解除一項高風險技術假設"
        },
        {
          "name": "試點",
          "meaning": "由真實操作人員測試完整流程"
        },
        {
          "name": "生產",
          "meaning": "在已簽署控制及服務水平內營運"
        }
      ],
      "sections": [
        {
          "heading": "封閉示範隱藏的缺口",
          "introduction": "示範經常省略生產工作中最重要的狀態及責任。",
          "checks": [
            {
              "name": "代表性質量",
              "requirement": "用有版本的常見、邊界、缺失數據、對抗及高影響案例取代精選例子，定義指標、門檻及失敗分析。"
            },
            {
              "name": "企業邊界",
              "requirement": "連接真實身份、租戶、權限、記錄系統、保留、審計、確認及禁止動作，而非共用測試帳戶。"
            },
            {
              "name": "營運完整度",
              "requirement": "實現隊列、重試、冪等、狀態驗證、延遲與可用性目標、監測、成本限制、降級、事故處理及支援。"
            }
          ]
        },
        {
          "heading": "把原型變成有人負責的服務",
          "introduction": "當具名團隊可在不依賴示範作者下作出及撤回營運決定，生產才真正開始。",
          "checks": [
            {
              "name": "業務責任",
              "requirement": "指定流程負責人、使用者、基線、預期價值、例外政策、採用方案、資金，以及擴大或停止權。"
            },
            {
              "name": "技術責任",
              "requirement": "分配模型、數據、整合、安全、發布、可觀測性、供應商及恢復責任，配合手冊及升級路徑。"
            },
            {
              "name": "變更證據",
              "requirement": "為提示詞、模型、檢索、工具、政策、數據及測試建立版本；重大變更重跑回歸並保留發布及回退記錄。"
            }
          ]
        }
      ],
      "procedure": [
        {
          "position": 1,
          "name": "建立生產缺口登記",
          "instruction": "按使用者、數據、權限、整合、評估、營運、成本、責任及退出比較 PoC 與目標流程。"
        },
        {
          "position": 2,
          "name": "建設一條完整路徑",
          "instruction": "實現最小端到端流程，包括例外、人工覆核、最終狀態、監測及恢復。"
        },
        {
          "position": 3,
          "name": "進行受控試點",
          "instruction": "限制使用者、數量、數據及權限，收集質量、可靠性、成本、採用、例外及業務證據。"
        },
        {
          "position": 4,
          "name": "簽署並分階段發布",
          "instruction": "只批准已測試範圍及權限，記錄剩餘風險與停止條件，在證據窗口通過後才擴大。"
        }
      ],
      "frequentlyAskedQuestions": [
        {
          "question": "PoC 何時算成功？",
          "answer": "當它回答原本設計要測試的具體不確定性時；這不自動代表方案已生產就緒或值得擴大。"
        },
        {
          "question": "PoC 程式碼應否重用？",
          "answer": "只有覆核架構、安全、測試、依賴、授權、數據處理、可觀測性及可維護性後才決定；重用不是預設。"
        },
        {
          "question": "最常阻礙生產的是甚麼？",
          "answer": "責任不清、評估不具代表性、數據與身份控制薄弱、整合不完整、缺少失敗處理，以及沒有可信營運經濟。"
        }
      ]
    },
    "zhHans": {
      "name": "AI 概念验证怎样变成生产系统？",
      "summary": "PoC 在受控条件下证明一个狭窄技术问题。生产则需要完整运营流程、代表性证据、真实数据与身份边界、可靠集成、问责负责人、恢复程序，以及可以安全扩大的权限层级。",
      "decisionSignals": [
        {
          "name": "PoC",
          "meaning": "解除一项高风险技术假设"
        },
        {
          "name": "试点",
          "meaning": "由真实操作人员测试完整流程"
        },
        {
          "name": "生产",
          "meaning": "在已经签署的控制和服务水平内运营"
        }
      ],
      "sections": [
        {
          "heading": "关闭演示隐藏的缺口",
          "introduction": "演示经常省略生产工作中最重要的状态和责任。",
          "checks": [
            {
              "name": "代表性质量",
              "requirement": "用有版本的常见、边界、缺失数据、对抗和高影响案例替代精选例子，定义指标、门槛和失败分析。"
            },
            {
              "name": "企业边界",
              "requirement": "连接真实身份、租户、权限、记录系统、保留、审计、确认和禁止动作，而不是共享测试账号。"
            },
            {
              "name": "运营完整度",
              "requirement": "实现队列、重试、幂等、状态验证、延迟与可用性目标、监控、成本限制、降级、事故处理和支持。"
            }
          ]
        },
        {
          "heading": "把原型变成有人负责的服务",
          "introduction": "当明确团队可以在不依赖演示作者的情况下做出和撤回运营决策，生产才真正开始。",
          "checks": [
            {
              "name": "业务责任",
              "requirement": "指定流程负责人、用户、基线、预期价值、异常政策、采用方案、资金，以及扩大或停止权限。"
            },
            {
              "name": "技术责任",
              "requirement": "分配模型、数据、集成、安全、发布、可观测性、供应商和恢复责任，配合手册与升级路径。"
            },
            {
              "name": "变更证据",
              "requirement": "为提示词、模型、检索、工具、政策、数据和测试建立版本；重大变更重跑回归并保留发布和回退记录。"
            }
          ]
        }
      ],
      "procedure": [
        {
          "position": 1,
          "name": "建立生产缺口登记",
          "instruction": "按照用户、数据、权限、集成、评估、运营、成本、责任和退出比较 PoC 与目标流程。"
        },
        {
          "position": 2,
          "name": "建设一条完整路径",
          "instruction": "实现最小端到端流程，包括异常、人工复核、最终状态、监控和恢复。"
        },
        {
          "position": 3,
          "name": "进行受控试点",
          "instruction": "限制用户、数量、数据和权限，收集质量、可靠性、成本、采用、异常和业务证据。"
        },
        {
          "position": 4,
          "name": "签署并分阶段发布",
          "instruction": "只批准已经测试的范围和权限，记录剩余风险与停止条件，在证据窗口通过后再扩大。"
        }
      ],
      "frequentlyAskedQuestions": [
        {
          "question": "PoC 什么时候算成功？",
          "answer": "当它回答原本设计要测试的具体不确定性时；这不自动代表方案已经生产就绪或值得扩大。"
        },
        {
          "question": "PoC 代码应该复用吗？",
          "answer": "只有复核架构、安全、测试、依赖、许可、数据处理、可观测性和可维护性后再决定；复用不是默认。"
        },
        {
          "question": "最常阻碍生产的是什么？",
          "answer": "责任不清、评估不具代表性、数据与身份控制薄弱、集成不完整、缺少失败处理，以及没有可靠运营经济。"
        }
      ]
    }
  },
  "limitations": [
    "This asset is provider-authored and is not independent validation or a claim of client results.",
    "It is an implementation aid, not legal, privacy, security, financial, procurement, or regulatory advice.",
    "Thresholds and controls must be adapted to the organisation, workflow, jurisdiction, and risk owners."
  ]
}