在欧盟将LLM应用从想法推向生产：什么真正阻碍了你的首次发布？

假设你有一个想法，将研究论文转化为针对产品经理的行业特定见解。你使用你选择的AI工具快速构建一个原型，展示给同事，并获得鼓励性反馈。现在你想把它变成一个客户会使用并付费的服务。在负责任地发布之前，必须改变什么？我正在探索这个转变，重点关注LLM应用构建和可观测性。我还在考虑开发实践培训，并最终围绕它提供服务。我想了解团队在决定构建或教授什么之前实际在哪里卡住。上述研究服务是一个例子，并非声称我已发布它。 以下是我试图挑战的清单： 1. 个人数据和实际适用的欧盟要求。什么个人数据会传递到模型、其提供者和我们的日志？合法依据是什么，我们能避免收集什么，以及如何处理透明度、删除和保留？对于AI法案，我将评估预期用途和我们的角色，而非假设每个代理都是高风险。哪些义务适用于此特定服务，我们需要什么证据？ 2. 有用的可追溯性，无需永久记录一切。如果客户质疑一个答案，我们能否重建来源、模型和提示版本、工具调用和相关批准？我们应该编辑或保留什么，保留多久，以及谁可以访问它？执行跟踪并不能完整解释模型的内部推理。我并非假设普遍法律要求归档每个跨度或应要求披露一切。 3. 滥用、提示注入和业务规则。用户可能试图让电子商务代理以1欧元出售100欧元的商品，使用我们的付费LLM访问执行无关任务，或提取内部数据。隐藏在检索论文或网页中的指令也可能重定向代理。你如何结合防护栏、服务器端价格验证、范围权限、租户隔离、速率限制和支出上限？哪些操作需要人工批准？ 4. 跨连接系统的问责制。一旦代理访问ERP、CRM或数据库，我们能否将操作与发起用户、租户、请求和代理身份关联起来？更重要的是，目标系统是否执行该身份允许的操作？仅凭跟踪ID无法保护数据。 5. 发布后的质量和价值。随着模型、提示和数据的变化，我们如何评估安全控制和答案质量？以研究为例：引用是否有效，声明是否有支持，发现是否有用？当用户报告不良答案时，我们能否区分检索失败、生成失败或工具失败？人们是否返回、节省时间并支付——我们从离开的人那里学到了什么？我还想衡量每个有用结果的成本，包括人工审查，并在系统失败时设置后备方案。 这可能不完整，部分可能对小规模首次发布过度设计。如果你已为客户发布LLM应用：哪个真正阻碍发布或事后引起麻烦的问题？发生了什么，你如何处理，以及哪些仍然痛苦？大约花了多少工程或审查时间？我也对安全推迟到后来的内容感兴趣。一个具体的例子比完整的清单更有用；无需机密细节。