x86 か x64 かは問題ではなく、バージョンが問題です。
.NET にはバージョンリダイレクトという、違うバージョンでコンパイルされていても動作する仕組みを持っています。
「アセンブリ バージョンのリダイレクト」
https://docs.microsoft.com/ja-jp/dotnet/framework/configure-apps/redirect-assembly-versions
%ORACLE_HOME%\ODP.NET のフォルダに PublisherPolicy というフォルダがあると思います。
この下に 2.x と4 フォルダがあって、その下に .config と .dll がセットになった Policy.x.xxx.Oracle.DataAccess~ というファイルがありますね。
これが発行者ポリシーです。
.config ファイルの一つをメモ帳で開いてみると
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342"/>
<bindingRedirect oldVersion="4.112.0.0-4.112.9999.9999" newVersion="4.121.2.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
のようになっており、ODP.NET の 4.112.0.0 から 4.112.9999.9999 が要求されたら 4.121.2.0 の dll を動かしますという定義になっています。
実行環境に登録されている発行者ポリシーがこのようになっており、開発環境で参照設定している ODP.NET のバージョンがこの範囲であれば、問題なく動かすことができます。
ただ、これらの設定が正常に登録されないバージョンがあるらしく、うまく動かすためには、OraProvCfg.exe を実行して、ポリシーファイルを登録するか、実行環境のバージョンに合わせた dll を参照設定してリリースする必要があると思います。
#追記:質問を見誤っていました。
大変失礼しました。
私の場合は、開発もリリースも「AnyCPU」で参照設定は 32bit の ODP.NET です。
つまり、Visual Studio 上の開発ツールは 32bit の ODP.NET、デバッグは 64bit の ODP.NET を使用していることになります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。