Home / Guia de tomada de decisão do projeto / Direitos de propriedade intelectual e atribuição de ativos para projetos AI
PROJECT DECISION GUIDE

Como os dados, modelos, dicas e direitos de propriedade intelectual do projeto AI são acordados

O projeto AI não só gera códigos fonte, mas também amostras de missão, regras de processamento de conhecimento, configuração de alerta, coleta de avaliação, adaptação de modelo, ferramentas de agente e feedback operacional. Escrever apenas “direitos de propriedade intelectual para clientes” pode ainda deixar uma grande quantidade de ativos que determinam se o sistema pode continuar a operar.

Responde à pergunta.

Propriedade intelectual e atribuição de ativos para o projeto AI

O anexo do contrato deve distinguir entre os activos originais do cliente, o resultado exclusivo do projecto, a capacidade geral do fornecedor e os activos autorizados de terceiros, e acordar em propriedade, âmbito de utilização, direitos de modificação, relicenciação, confidencialidade, supressão de retorno após a conclusão do projecto e alternativas, respectivamente. As conclusões jurídicas específicas serão revistas por um responsável jurídico profissional em conjugação com o contrato e a licença em vigor, e esta página será utilizada para ajudar a completar a lista de activos para fins técnicos e de adjudicação de contratos.

SCOPE & BUDGET LEVELS

Primeiro, entradas claras para o limite por fase do projeto

As camadas seguintes são utilizadas para estabelecer uma linha de base para o orçamento e a aceitação, e o âmbito de aplicação real ainda terá de ser avaliado em relação aos requisitos de status quo, interface e tempo.

Fase 1

Inventário de activos

Primeiro, sabes o que está em uso e o que está nele.

Conhecimento de dados do cliente, componentes de código aberto, serviços de negócios, framework comum, código fonte do projeto, configuração, dicas, avaliação e lista de números de conta

Fase 2

Compromissos de classificação de contratos

Identificação dos direitos e limitações para diferentes ativos

Propriedade, posse, modificação, ambiente de implantação, uso comercial, confidencialidade, relicenciamento, custo e duração

Fase 3

Autenticação de entrega e saída

Garantir que os direitos estejam realmente operacionais

Número da conta do armazém, formato do arquivo, substituição da chave, implantação de compilação autônoma, exclusão da exportação de dados e caminho alternativo de terceiros

DECISION FACTORS

Elementos-chave a controlar para a tomada de decisões

Em primeiro lugar, identificam-se os limites da contenção e da responsabilidade, depois comparam-se as vias técnicas e as modalidades de cooperação.

01

Dados do cliente e conhecimento empresarial

c) Esclareça para que fins os documentos, ordens, diálogos, regras e feedback fornecidos pelas empresas são utilizados apenas, se a formação é permitida e quando são devolvidos ou suprimidos.

02

Modelo básico e API

A maioria dos modelos de terceiros não transfere a propriedade com o projeto e deve identificar números de conta, termos, áreas de uso, mudanças de modelo e rotas alternativas.

03

Dicas, regras e fluxos de trabalho

A configuração exclusiva do projeto pode determinar a eficácia operacional e exigir o acordo sobre o formato de entrega, direitos de revisão, histórico da versão e os limites do modelo genérico para o fornecedor.

04

Base de conhecimento e avaliação

Os rótulos de divisão, configurações de índice, perguntas, erros de marcação e conjuntos de tarefas de regressão devem ser incluídos nos ativos do projeto e confidencialidade.

05

Aplicação do código-fonte e implantação

Esclareça a frente, parte de trás, interface, ferramentas de agente, scripts de banco de dados, arquivos de construção, configurações de infraestrutura e direitos de desenvolvimento secundários.

06

Componentes de código aberto e comercial

A licença, declaração de direitos autorais, restrições de distribuição, assento ou taxa de chamada é especificada para evitar a entrega do projeto e para achar impossível de usar legalmente.

07

Geração de conteúdo e responsabilidade operacional

O mecanismo para lidar com o risco de abuso, erro e conformidade.

08

Sair para alternar com o fornecedor

Confirmar a exportação de dados, transferência de conta, substituição chave, autorização contínua de componentes genéricos, suporte transitório e certificação de des-listagem.

Preparação de recomendações antes da comunicação ou avaliação

Conhecimentos de dados e ativos de marca pré-existentes dos clientesDicas e avaliações de configuração de fonte de projetoQuadro comum para os fornecedores e direitos de propriedade intelectual pré-existentesLista de componentes comerciais dos serviços de nuvem modeloDireito de modificação de título e âmbito comercialFormação em matéria de retenção de dados para remoção e confidencialidade dos rendimentosDocumentos de implantação de contas de armazém e reprodução independenteCertificados de transição e de remoção pós-contratação

Caminho sugerido para a implementação

O processo de recepção e inspeção envolve não só a assinatura da lista de resultados, mas também a certificação da autoridade de depósito pelo receptor, a dependência de licenças, exportação de dados e implantação independente. Projetos envolvendo grandes quantidades ou distribuição comercial devem ser revisados por profissionais de propriedade intelectual e conformidade de dados.

DECISION WORKSHEET

Traduzindo o projeto AI propriedade intelectual e atribuição de ativos para a tomada de decisões executáveis

As seguintes planilhas ajudam as empresas a organizarem conselhos vagos em insumos de fornecedores, de aprovação interna e de recebimento de projetos.

O que deve conter um resumo comparável das avaliações?

No mínimo, o conhecimento original dos dados e os ativos de marca do cliente, as dicas de configuração e a coleta de avaliação de fontes exclusivas do projeto, o framework comum do fornecedor e os direitos de propriedade intelectual pré-avaliados, a lista de componentes de negócios abertos aos serviços de nuvem modelo, juntamente com uma indicação do volume de negócios atual, tempo médio de processamento, anomalias principais, sistemas em vigor, privilégios de dados, dependência de terceiros e janelas de go-live. A mesma versão de informação é fornecida a diferentes fornecedores e solicita que os pressupostos, exclusões, cooperação com o cliente, entrega e aceitação de evidências sejam apresentados separadamente para evitar comparar o preço total de apenas uma fronteira.

Por exemplo, a empresa espera que o projeto economize 160 horas de trabalho por mês, mas este valor deve ser dividido em número de tarefas, economia de tempo única, taxas de adoção e razões de revisão manual. Se apenas 40% dos usuários usarem o primeiro período, ou se o novo processo aumentar o processo de revisão, os benefícios reais serão significativamente menores do que a estimativa aparente.

Quatro tipos de evidência recomendada para interrogatório durante a comunicação do fornecedor

A primeira é a evidência de escopo: consistência de versões de demanda, processos de negócios, protótipos, interfaces e exclusões; a segunda é a evidência de engenharia: se tecnologias semelhantes têm estruturas acessíveis, métodos de gerenciamento de código, testes, implantação e gerenciamento de problemas; a terceira é a evidência de pessoal: se os participantes reais, estágios de entrada, responsabilidades e mecanismos de substituição são claros; e a quarta é a evidência de entrega: como códigos fonte, dados, números de conta, documentos, treinamento, garantia de qualidade e transporte são entregues. É normal que os fornecedores não possam fornecer confidencialidade ao cliente na fase de licitação, mas devem ser capazes de explicar seus próprios métodos e as evidências que podem ser desenvolvidas no âmbito deste projeto.

Recomenda-se que a clareza do âmbito, a confiança crítica, a capacidade da equipa, a aplicabilidade da aceitação e a aquisição a longo prazo sejam avaliadas separadamente e que a base para cada pontuação seja registada. Se um programa for mais barato, a interface, migração, testes ou responsabilidade em linha é excluída, então deve ser convertido para o mesmo calibre de entrega antes da comparação.

O princípio do acórdão

Esta página fornece um quadro de tomada de decisão que não constitui uma oferta fixa ou compromisso de desempenho.

FAQ

FAQs

As questões mais comuns antes da cooperação são claramente indicadas com antecedência.

Os clientes podem possuir modelos após usar um modelo de terceiros grande?+

Normalmente não. O cliente tem seus próprios dados, aplicativos de projeto e resultados exclusivos contratuais; os direitos e limitações para o uso do modelo subjacente são determinados pelos termos do fornecedor modelo.

A dica é necessariamente um cliente?+

Sem harmonização automática das respostas, deve ser feita uma distinção entre as regras dos clientes, as especificações dos projectos e os modelos genéricos de fornecedores, e o âmbito da entrega e utilização deve ser claramente definido no contrato.

Os componentes de código aberto afetarão a comercialização?+

Possíveis. As licenças diferentes exigem requisitos diferentes para modificação, distribuição, abertura do código fonte e SaaS, e a cadeia de dependência pode conter várias licenças que precisam ser compiladas e revistas.

Por que o código fonte de entrega ainda não pode ser assumido?+

O código fonte em si não é suficiente para restaurar o sistema completo se a construção depender, contas de modelo, configuração de alerta, linhas de streaming de conhecimento, bases de dados, substituição chave, documentos de implantação e licenças estão faltando.

DECISION FAQ

Questões comuns relacionadas com os projectos em curso

Confira todas as 265 perguntas.
Programa de arranque e selecção de programas

As informações podem ser fornecidas após a celebração de um acordo de confidencialidade?

Pode assinar um acordo de confidencialidade para fornecer informações.

Ver resposta completa
Programa de arranque e selecção de programas

Como devem ser selecionados sistemas de código baixo, código aberto e desenvolvimento personalizado?

O código baixo é adequado para processos que são claros, modificáveis e capazes de plataforma para cobrir aplicações internas mais elevadas; sistemas de código aberto são adequados para produtos de área madura, que podem atender à demanda através da configuração e desenvolvimento secundário; personalizar o desenvolvimento de projetos que são adequados para processos diferenciados, integração complexa, desempenho ou requisitos de controle de produtos mais elevados. A seleção é feita com uma comparação do custo total e capacidade de saída por três a cinco anos, em vez de apenas com o primeiro preço. As empresas também podem usar rotas de combinação, permitindo que diferentes tecnologias assumam o limite de negócios mais adequado.

Ver resposta completa
Contratos, pagamentos, alterações e entrega de projetos

Quais informações são necessárias para a aceitação e inspeção do projeto de software?

O objetivo da informação é demonstrar que o sistema atende às normas acordadas e que o cliente pode continuar a operar e assumir o controle.

Ver resposta completa
Contratos, pagamentos, alterações e entrega de projetos

O projeto de software foi adiado. O que devemos fazer com o A?

Pare de pedir apenas a porcentagem de conclusão, e peça à equipe para fornecer uma lista de resultados operacionais, empregos remanescentes, riscos e dependência. Distinguir entre aumento de escopo, colaboração do cliente, questões técnicas ou gestão de fornecedores leva a atrasos. Reformular o plano de recuperação de recepção e inspeção com base em fatos e congelar novos requisitos não críticos.

Ver resposta completa