なぜこれらのポリシーのほとんどが失敗するのか
共通の失敗は、テクノロジーについて書くことです。特定のツールを名指ししたり、AIを包括的に禁止するポリシーは、生成機能が日常的なソフトウェアに既に組み込まれているため、リリースサイクルごとに古くなり、公開した日から曖昧になります。
2つ目の失敗は、作業を行う人々ではなく、弁護士のために書くことです。午後の4時にヘッダー画像を選んでいるデザイナーは14ページの文書を読みません。読まれないポリシーはポリシーではありません。
3つ目は、何かが発見された際の対応が決められていないことです。チームは禁止令を書き、過去の素材から生成された画像を発見しますが、誰かを非難すること以外の手順を持っていません。
機能するポリシーは短く、ツールではなく画像そのものを記述し、避けるべきことではなく、取るべき行動を人々に伝えます。
決定1：どこで許可されるか
これがすべてであり、2文で収まります。分かれ目は、画像が装飾の役割を果たしているか、証拠の役割を果たしているかです。
生成された画像はOK
- 抽象的で装飾的なヘッダー
- コンセプトイラスト
- 背景とテクスチャ
- 社内資料と草案
- 明らかに様式化されたもの
生成された画像はNG
- ケーススタディと証言
- 実在の顧客を描写したもの
- ビフォーアフター写真
- ニュースやイベント報道
- 実在製品の製品写真
右の列には共通の特性があります。それは、画像が事実を主張しているということです。これこそが書き留めるべきテストです。ツールが将来どのように変化しても生き残り、専門家でない人でも適用できるからです。
決定2：誰が宣言するか
宣言は知識がある場所、つまり画像を作成または調達した本人が行う必要があります。下流でのチェックでは、最初から取得されていなかった情報を復元することはできません。
実際には、すべてのサプライヤー契約に1条項を入れ、アセットを保持するシステムに1つのフィールドを追加することを意味します。代理店、フリーランサー、ストック素材のサブスクリプションのすべてが生成されたものか明記する必要がありますが、誰も求めていないため、自発的に提供する者はほとんどいません。
社内の場合は、会話ではなくフィールド（入力欄）で対応します。アップロード時にその画像がどこから来たかを記録する必須のメモを残すだけで、後日の調査の手間を省けます。
決定3：フラグが立った時に何が起こるか
必要な時になってから慌てて対応するのではなく、事前に対応手順を書き留めておいてください。時間的なプレッシャーの下で行う即興の対応こそが、チームが不公平に振る舞う原因です。フラグが立った画像は「確認」であり、「告発」ではありません。
-
ソースに尋ねる
供給した本人が、大抵は一言で答えてくれます。フラグのほとんどはここで解決し、その解決の多くは通常の編集プロセスです。
-
原本を要求する
生のファイルやカメラのオリジナルデータは、どんな解析結果よりも確実に判断を下せます。
-
スコアではなく配置で決める
生成されたヘッダーは残して良い。生成されたケーススタディの写真は、スコアに関係なく差し替える。
-
スコアではなく結果を記録する
何を行い、なぜ行ったか。特定のサプライヤーに対する数値の履歴リストは、誰の役にも立たないプロファイルです。
-
ブリーフ（指示書）を修正する
同じサプライヤーで何度もフラグが立つなら、問題は彼らへの指示内容です。
3番目のステップこそが、ポリシーの誠実さを保つものです。検出結果は、編集上の配置についての決定に対する入力に過ぎません。数値を優先して決定を下すと、誰にも説明できない一貫性のない結果が生まれます。
決定4：何を保管するか
保存規定は、良かれと思った意図がデータ保護の問題に変わる場所です。すべてのチェックを記録したいという誘惑に駆られますが、その結果、特定の個人やサプライヤーにスコアが紐付いた運用記録ができてしまいます。
アセットとともに結果を保存してください：何であるか、どこから来たか、宣言されたか。誰にフラグが立ったかの検索可能な履歴は保持しないでください。それは独自の正当化を必要とするプロファイリングであり、正当な理由を持つことは稀です。
身分証明書や人に関するものであれば、多くを保持せず、必要最低限の期間だけ保持してください。
コピーして使える記入例
どれほど簡潔にできるかを確認しておくと役立ちます。以下は5つの文で構成された完全なポリシー案です。これは多くのチームが必要とする量より長く、また多くのチームが作成するものより短くなっています。
生成画像は装飾、図解、内部資料として使用できます。実在の人物、場所、出来事、顧客、または製品について事実を主張するいかなるものにも使用してはなりません。サプライヤーは、すべての成果物において生成コンテンツであることを宣言しなければなりません。
画像に疑義が生じた場合、提供者にオリジナルファイルの提出を求めます。判断はスコアではなく、画像がどのような文脈で使用されているかによって行われます。結果は提供者ではなく、資産に対して記録されます。
以上がすべてです。長い文書に含まれるその他の内容は、これらの文の言い換えであるか、あるいは読者が読む頃には変更されているであろうツールの説明に過ぎません。
導入の進め方
誰も知らないポリシーは、ポリシーがないのと同じです。文言よりも導入を左右するのは、意思決定が行われる場所にルールを配置することと、準拠する方法を容易にすることの2点です。
前者は、共有ドライブの文書ではなく、ブリーフテンプレートへの記載と資産システム内のフィールド設置を意味します。後者は、ルールを守ることが無視するよりも遅くならないよう、承認済みの装飾画像ソースを用意しておくことを意味します。
このプロセスを経験したチームからの最後のアドバイスです。ポリシーには日付を入れ、見直し月を定めてください。ここのすべてはツールの機能と規制当局の要件に依存しており、どちらも変化します。見直し日のない文書は、更新されるのではなく、知らぬ間に形骸化していきます。